AUTHSCAN: Automatic Extraction of Web Authentication Protocols from Implementations∗ Guangdong Bai?, Jike Lei?, Guozhu Meng?, Sai Sathyanarayan Venkatraman?, Prateek Saxena?, Jun Suny, Yang Liuz, and Jin Song Dong? ∗National University of Singapore ySingapore University of Technology and Design zNanyang Technological University Abstract than 250 million people reportedly use it every month as of 2011 [7]. Ideally, authentication protocols should be for- Ideally, security protocol implementations should be for- mally verified prior to their implementations. However, mally verified before they are deployed. However, this is majority of web sites do not follow this principle. Au- not true in practice. Numerous high-profile vulnerabilities thentication protocols have historically been hard to design have been found in web authentication protocol implemen- correctly and implementations have been found susceptible tations, especially in single-sign on (SSO) protocols imple- to logical flaws [31, 41]. Web authentication protocols are mentations recently. Much of the prior work on authentica- no exception—several of these implementations have been tion protocol verification has focused on theoretical foun- found insecure in post-deployment analysis [16, 29, 39, 42]. dations and building scalable verification tools for checking There are three key challenges in ensuring that appli- manually-crafted specifications [17, 18, 44]. cations authenticate and federate user identities securely. In this paper, we address a complementary prob- First, most prior protocol verification work has focused on lem of automatically extracting specifications from im- checking the high-level protocol specifications, not their plementations. We propose AUTHSCAN, an end-to-end implementations [13,21,44]. In practice, however, checking platform to automatically recover authentication protocol implementations is difficult due to lack of complete infor- specifications from their implementations. AUTHSCAN mation, such as missing source code of some protocol par- finds a total of 7 security vulnerabilities using off-the-shelf ticipants. Second, verifying authentication using off-the- verification tools in specifications it recovers, which include shelf tools requires expert knowledge and, in most prior SSO protocol implementations and custom web authentica- work, conversion of authentication protocol specifications tion logic of web sites with millions of users. to verification tools has been done manually. However, sev- eral custom authentication protocols are undocumented. As 1 Introduction new protocols emerge and the implementations of existing protocols evolve, manual translation of every new proto- Web authentication mechanisms evolve fast. Many web col becomes infeasible. Moreover, manual translation is sites implement their own authentication protocols and rely tedious and can be error-prone. Finally, the authentication on third-party mechanisms to manage their authentication of the communication between protocol participants often logic. For example, recent single-sign on (SSO) mecha- goes beyond the initial establishment of authentication to- nisms (e.g., Facebook Connect, SAML-based SSO, OpenID kens, which the high-level specifications dictate. In prac- and BrowserID) have formed the basis of managing user tice, checking the end-to-end authentication of communica- identities in commercial web sites and mobile applications. tion involves checking if the authentication tokens are ac- For example, OpenID currently manages over one billion tually used in all subsequent communications and making user accounts and has been adopted by over 50,000 web sure they are not sent on public communication channels sites, including many well-known ones such as Google, or stored in persistent devices from which they can leak. Facebook and Microsoft [5]. As another example, Face- Techniques to address these practical problems of existing book Connect is employed by 2 million web sites and more implementations are an important area which has received relatively lesser attention. ∗Prateek Saxena, Jun Sun and Yang Liu have contributed equally to this work. Our Approach. In this paper, we present a frame- work called AUTHSCAN to automatically extract the formal knowledge—one of these was found independently by a specifications of authentication protocols from their imple- concurrent work [33] and the remaining are previously un- mentations. Then, these specifications are directly checked known. In particular, we find two flaws in Facebook Con- for authentication and secrecy properties using off-the-shelf nect Protocol and one flaw in BrowserID, which arise be- verification tools [10, 18, 22]. AUTHSCAN can automati- cause the freshness of messages is not guaranteed in the cally confirm the candidate attacks generated by the ver- protocol implementations. An attacker is thus able to perpe- ification tools and report the true positives (confirmed at- trate replay attacks to acquire unauthorized authentication tacks) in most cases we study. In some cases, AUTHSCAN credentials. Several other vulnerabilities are due to unsafe does not know the attacker’s knowledge set enough to gen- implementation errors in creating and maintaining secrecy erate confirmed attacks — in such cases, it generates secu- of authentication tokens. For example, we find that a web rity warnings containing precise communication tokens that site employing Windows Live Messenger Connect grants need to be manually reviewed by the security analyst. the end user a publicly known value as a credential after the We design an intermediate language TML to bridge the user has been authenticated to Windows Live. gap between the detailed implementation of an authentica- Contributions. We make the following main contributions tion protocol and its high level semantics that can be used in this paper: by the verification tools. We show that TML is sufficient • Automatic Extraction Techniques. We propose au- to capture the communications between protocol partici- tomatic techniques to extract the authentication pro- pants and their internal actions. AUTHSCAN assumes no tocol specifications from their implementations. Our knowledge of the protocol being inferred and does not re- approach works with only minimal number of user in- quire the full source code of the implementation. We pro- puts (Section 2.3) and reasonable assumptions (Sec- pose a refinement method to deal with partial availability tion 3.2), without requiring any knowledge of the pro- of the code implementing the protocol (e.g., if the code tocol. Our techniques gracefully adjust the precision of located on a web server is not available). It starts with the inferred protocol based on how much source code an initial abstraction of the protocol specification, and it- implementing the protocol is visible to the analysis. eratively refines the abstraction until it reaches a fixpoint. • End-to-end System. We build AUTHSCAN, an end- To perform this refinement, we propose a novel hybrid in- to-end system that embodies these techniques. AUTH- ference approach to combine a whitebox program analysis SCAN is designed to be extensible and configurable— with a blackbox differential fuzzing analysis. In particular, it can utilize several off-the-shelf verification tools the whitebox analysis performs dynamic symbolic analysis (ProVerif [18] or PAT [38]), and can be extended to on the available code to extract precise data semantics and model different attack models. the internal actions of the protocol participants. The black- • Practical Results. We apply our approach to several box analysis infers the protocol implementation by prob- real-world web sites, including several using impor- ing the protocol participants and comparing the changes in tant SSO protocols like Facebook Connect Protocol, their response. Our final inferred specification in TML can BrowserID and Windows Live Messenger Connect. be directly translated into modeling languages used by off- We successfully find 7 security flaws in their imple- the-shelf verification tools and can be configured to verify mentations. against a variety of attacker models [17, 24]. Our techniques focus on recovering as much protocol se- 2 Challenges & Overview mantics as possible from dynamic executions of the proto- col; we do not aim to find complete specifications. Instead, Security analysts often need to guarantee the correctness we aim to recover fragments of the protocol with enough of authentication protocol implementations without having precision to find interesting logic flaws. We apply AUTH- complete access to the source code. In this section, we ex- SCAN to study several real-world web sites, including three plain the problem and its challenges with an example. popular SSO protocols — Facebook Connect Protocol (2 2.1 A Running Example web sites), Browser ID (3 web sites) and Windows Live Messenger Connect (1 web site). We also test several stan- Consider one execution of a hypothetical single-sign on dalone web sites which implement their custom authentica- (SSO) protocol (similar to Facebook Connect) as shown tion logic and have millions of users sharing personal in- in Figure 1-(a). In our example, Alice wants to authenti- formation. AUTHSCAN successfully recovers precise (but cate herself to a service provider (SP) web site hosted at partial) models of their authentication logic, and formally sp.com by using her login credentials with an identity 1 verifies their authentication and secrecy properties against provider (IDP) hosted at idp.com . This example