1 / 27

Traffic-Guided SSO Security Study: Facebook and Google Integration

Explore the vulnerabilities of web-based Single Sign-On (SSO) schemes integrated with Facebook and Google. Learn about the three-party system in SSO and the potential adversarial scenarios. Utilize the BRM Analyzer tool to assess abstract traces of traffic for different adversary scenarios. Discover key findings from real-world SSO deployments, including the deployment of Google ID.

dlivingston
Download Presentation

Traffic-Guided SSO Security Study: Facebook and Google Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 1b 2a 1a 2b 3b BRM2 BRM1 IdP RP IdP RP A round trip = a browser request + its response A BRM = a response + the next browser request 1b: HTTP 302 response Location: facebook.com/foo?x=123&… 2a: GET facebook.com/foo? x=123&…

  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” Google’s signature correct ≠ All data on the message verified • 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. Impact • Acknowledgements from many companies • Security advisories published • News coverage any many others

  23. Lessons learned

  24. Understanding system details vs. logic reasoning • The work is about understanding system details of concrete deployments, not pure logic reasoning • Every flaw has its variations, which are in details of individual systems • The flaws are hard to foresee before we examine concrete deployment cases

  25. 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.

  26. 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.

  27. 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

More Related