Web-based SSO schemes are being deployed by more and more commercial websites

1. Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services

2. Web-Based Single Sign On (SSO) • Web-based SSO schemes are being deployed by more and more commercial websites • Sears.com incorporating Facebook logon • Smartsheet.com incorporating Google ID logon • Many major companies are providing SSO schemes • A majority of web users (77%) prefer SSO to be offered by websites

3. Three parties in SSO Browser representing a user (who already signed into the IdP as Alice) • Goal of SSO scheme: to convince the RP that the IdPbelieves that this particular browser is representing Alice Alice ID Provider (IdP), e.g., Facebook, Google, etc Relying party (RP), e.g., sears.com, etc.

4. Previous research and our motivation A “formalized model” • Research about SSO in the protocol verification community • To build tools for SSO protocol verification • To show effectiveness of the tools in verifying security properties of formalized protocols or discovering protocol flaws. • Our focus • To report our broad “field study” of commercially deployed SSO systems in the wild. • To understandto what extent and why they are vulnerable. A real-world system

5. Challenge in analysis of real-world SSO • Detailed server logic and server-server communication are invisible to us. • We can only see contents in browser traffic. • Positive side: making our findings more serious • No reason why attackers with real malicious intents cannot discover whatever we discover in this study. Browser Invisible to us IdP RP

6. Vulnerabilities reported in this paper • In most cases, a vulnerability was confirmed on many RP websites. • Every vulnerability allowed an attacker to sign in as the victim. [video]

7. Background

8. Browser relayed message (BRM) browser browser  • Two equivalent views of browser traffic: round trips vs. BRMs 1a 3a 3b 4a 1b 2a 1a 2b 4b BRM2 BRM3 BRM1 IdP RP IdP RP A round trip = a browser request + its response A BRM = a response + the next browser request • We reason about an SSO process as a sequence of BRMs • Because a BRM naturally describes how the SSO process transitions from one step to the next.

9. An example BRM src=a.comdst=Facebook.com/foo.php Set-cookies: sessionID=6739485 Arguments: x=123 & user=john Cookies: fbs=a1b2c3 & foo=43da2c2a

10. Adversary scenarios

11. When Bob is involved Alice’s browser Bob • There are four “SSO triangles” • Alice-IdP-Bob, Bob-IdP-RP, Alice-IdP-RP and Alice-Bob-RP • We do not consider Alice-Bob-RP, which would require Bob to act as an IdP IdP RP

12. The three adversary scenarios corresponding to three SSO triangles (A) Bob as a client (B) Bob as another relying party RP IdP RP IdP (C) Bob as a parasite page in Alice’s browser RP IdP

13. The BRM Analyzer

14. The BRM analyzer • An online tool that we built to derive abstract traces from concrete traffic traces • URL: http://sso-analysis.org • How to use the analyzer • Collect three traffic traces. (An example trace) • Submit them to the BRM analyzer • The analyzer will automatically generate abstract traces for adversary scenarios (A) (B) (C) as explained earlier. • Example: scenario (A) of smartsheet’s integration of Google ID. • An abstract trace shows the readability and the writability of each element, and how the element propagates between BRMs. • How the analyzer works is described in the paper.

15. Studied cases and findings

16. BRM1:src=RP dst=http://IdP/accounts/o8/ud Arguments: openid.ns[WORD] & openid.claimed_id[UU]  & openid.identity[UU]  &openid.return_to[URL]{RP/b/openid}  & openid.realm[URL]{RP/b/openid}  & openid.assoc_handle[BLOB]  & openid.openid.ns.ext1[WORD]  & openid.ext1.type.email[WORD]  & openid.ext1.type.firstname[WORD]  & openid.ext1.type.lastname[WORD]  & openid.ext1.required[LIST]  BRM2:src=IdPdst=http://!IdP/openid2/auth Arguments: st[MU][SEC]  BRM3: src=!IdPdst=https://RP/b/openid Arguments: openid.ns[WORD]  & openid.mode[WORD] & openid.response_nonce[SEC] & openid.return_to[URL]  & openid.assoc_handle[BLOB]  & openid.identity[UU] & openid.claimed_id[UU]& openid.sig[SIG] & openid.signed[LIST]  & openid.opEndpoint[URL]{IdP/accounts/o8/ud}& openid.ext1.type.firstname[WORD]  & openid.ext1.value.firstname[UU] & openid.ext1.type.email[WORD]  & openid.ext1.value.email[UU] & openid.ext1.type.lastname[WORD]  & openid.ext1.value.lastname[UU] protected by openid.sig Deployment of Google ID • Google ID is based on OpenID. • Abstract trace for scenario (A) is shown here. • Important elements • Openid.ext1.required in BRM1 • Openid.sig in BRM3 • Openid.signed in BRM3 • Openid.ext1.required is propagate to Openid.signed

17. Deployment of Google ID (cont.) • A simplified illustration of the SSO scheme Alice’s browser (BRM2: unimportant, ignored in this talk) BRM1: realm= the RP’s identityrequired=(email,firstname,lastname) BRM3: signed=(email,firstname,lastname)email=“alice@a.com”firstname=“Alice”lastname=“Smith”signature=“HRU436ETQ95TR939” Google ID service Relying party website

18. The attack • BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson”email=“alice@a.com” • Reality: many RP websites use email address to identify users. • Suppose Bob knows Alice’s email address. BRM1: realm= the RP’s domainrequired=(email,firstname,lastname) Bob’s browser • BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson” BRM1: realm= the RP’s domainrequired=(email,firstname,lastname) Relying party website Google ID service Google’s signature verified. Welcome, user “alice@a.com”!

19. Facebook Connect (Facebook’s SSO) • Abstract trace for scenario (B) is shown here. • app_id, representing the RP’s identity, is writable by Bob. • result, the secret for authentication is sent to Bob in BRM3. • Isn’t there an obvious vulnerability? • In BRM1, set app_id value to be the app_id of the target RP; • In BRM3, Bob will receive the result corresponding to the target RP • Now, Bob would be able to login to the target RP. • Does this obvious attack work? Hi Facebook, I am NYTimes.com BRM1:src=Bob.comdst=http://!IdP/permissions.req Arguments: app_id[BLOB] & cb[SEC][BG] & next[URL]{ http://!IdP/connect/xd_proxy.php? origin[BLOB]  & transport[WORD]  } & … & … & … (other 13 elements ) Facebook generates result to allow login to NYTimes.com BRM2:src=!IdPdst=http://!IdP/xd_proxy.php Arguments: origin[BLOB]& transport[WORD]& result[SEC]& … & … (other 4 elements) BRM3:src=!IdPdst=http://Bob.com/login.php Arguments: origin[BLOB]& transport[WORD]& result[SEC]& … & … (other 3 elements ) result is passed to Bob.com

20. How Facebook SSO really works • The naïve attack did not succeed, because Facebook relies on the client-side same-origin-policy to pass the secret securely. • One of the client-side mechanisms is Adobe Flash • Below is the benign scenario • Both Flash A and Flash B are loaded from Facebook (fbcdn.net) • The secret is sent from Flash A to B (the same-domain communication) • Flash B makes sure that the secret is only sent to an HTML DOM in the intended domain (corresponding to the previous declared app_id) http://bob.com

21. The vulnerability • Adobe Flash can only do same domain communication? A wrong assumption • “Unpredictable domain communication” • As long as Flash A is willing to send, and Flash B is willing to receive, they can communicate in different domains. • So Flash B can come from bob.com, and thus obtain the secret from Flash A. Unpredictable domain comm.

22. Janrain • The most complicated case in our study • Over 365,000 websites use Janrain • It is a “wrapper” SSO service, similar to Azure ACS. • A website can just integrate Janrain to enable many SSO schemes altogether. • For a real IdP, the Janrain service acts as an RP; for the real RP website, Janrainservice acts as an IdP. Two SSO triangles here. Browser Janrain The real IdP Janrain’s user interface The real RP

23. A TOCTTOU (time-to-check-to-time-to-use) attack against Janrain • The flaw (in the browser-Janrain-RP triangle) • Domain whitelisting is a crucial basis for Janrain’s security • E.g., the whitelist of foo.com: *.foo.com, *.foo.rpxnow.com • The main task of our attack is to bypass the whitelist-checking of an URL • A TOCTTOU (time-to-check-to-time-to-use) attack is feasible • Many details in the paper Bob’s browser Janrain foo.com Normal SSO: BRM1 – BRM7 Bob.com (claiming the identity of foo.com) Bob.com (intentionally whitelisting foo.com’sdomain) Janrain Janrain BRM1 to satisfy the whitelist checking BRM2- BRM7 to steal the secret

24. Impact • Acknowledgements from many companies • Security advisories published • News coverage any many others

25. Lessons learned

26. Summery of the studied cases • Commonalities in our investigations • Only two types of tokens: secret token or authentic token. • Only three adversary scenarios. • Investigation focus: how a secret token is propagated and how an authentic token is protected by a signature. • Variations in the discovered vulnerabilities • Variations are in the details of individual systems. • How a signature’s coverage is determined • How the browser protects the secrecy of a token • How BRM destinations are checked or whitelisted by servers • How accounts are linked • Many others …

27. protocols vs. real systems • Real-world integration is through APIs. • Through integrating web APIs, SDKs and sample code offered by ID providers • A protocol serves merely as a loose guideline – many grey areas. • The underlying runtime systems matter. • A logically correct protocol can be insecure if its designers or its integrators did not fully understand the underlying runtime systems. • Some protocol results are so confusing that even reasonable developers misunderstand and misuse them. • How to call APIs securely can be very challenging. • Similar situation in C/C++: strcpy, setuid, seteuid, setguid. Very tricky to call.

28. So, what kind of analysis tools do we need? • The main value is to help a security analyst understand the system • We spent more effort was on understanding than on pure logic thinking • A tool to support an adaptive and iterative investigation process • Our investigation experience: • start with partial knowledge of the system • design new tests to probe • reason about the test results to improve our understanding • Repeat until a viable path is found. • A tool assuming our complete knowledge is less useful • “Tell me everything upfront, and I will tell you everything I find” – not very useful for real-world system analysis.

29. Conclusions • Logic flaws exist in many commercially deployed SSO websites • Every one of the flaws allows attackers to get into victims’ accounts. • They can be discovered using browser traffic without insider knowledge. • They are issues in real-world deployments, not protocol designs. • IdP developers and RP developers should work together for secure integrations • ID providers: simplify the APIs provided to RP websites; anticipate all reasonable interpretations of your API specs. • RP developers: do not blindly count on ID providers for security, as each integration scenario is different; you must perform an end-to-end testing after your integration is done.

30. Acknowledgement • Martín Abadi • Manuel Caballero • Alex Halderman • Cormac Herley • Zhou Li • ShazQadeer • David Ross • NikSwamy • Helen Wang • Yi-Min Wang Visit http://sso-analysis.org