Signing Me onto Your Accounts through Facebook and Google:
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

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


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. Web-Based Single Sign On (SSO). Web-based SSO schemes are being deployed by more and more commercial websites

Download Presentation

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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]


Background

Background


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

An example BRM

src=a.comdst=Facebook.com/foo.php

Set-cookies: sessionID=6739485

Arguments: x=123 & user=john

Cookies: fbs=a1b2c3 & foo=43da2c2a


Adversary scenarios

Adversary scenarios


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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


The brm analyzer

The BRM Analyzer


Web based sso schemes are being deployed by more and more commercial websites

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.


Studied cases and findings

Studied cases and findings


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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 protected]=“Alice”lastname=“Smith”signature=“HRU436ETQ95TR939”

Google ID service

Relying party website


Web based sso schemes are being deployed by more and more commercial websites

The attack

  • BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Jo[email protected]

  • 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 [email protected]!


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

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


Web based sso schemes are being deployed by more and more commercial websites

Impact

  • Acknowledgements from many companies

  • Security advisories published

  • News coverage

any many others


Lessons learned

Lessons learned


Web based sso schemes are being deployed by more and more commercial websites

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 …


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

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.


Web based sso schemes are being deployed by more and more commercial websites

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


  • Login