1

Signing Me onto Your Accounts through Facebook and Google:

A Traffic-Guided Security Study of Commercially Deployed

Single-Sign-On Web Services

Rui WangIndiana University

Bloomington

Shuo ChenMicrosoft Research

Redmond

XiaoFeng WangIndiana University

Bloomington

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

Sears.com incorporating Facebook logonSmartsheet.com incorporating Google ID logonMany major companies are providing SSO schemes

A majority of web users (77%) prefer SSO to be offered by websites

2

Web-Based Single Sign On (SSO)

Three parties in SSO Browser representing a user (who already signed into the IdP as Alice)

ID Provider (IdP), e.g., Facebook, Google, etc

Relying party (RP), e.g., sears.com, etc.

Goal of SSO scheme: to convince the RP that the IdP believes that this particular browser is representing Alice

Alice

A real-world system

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 focusTo report our broad “field study” of commercially deployed SSO systems in the wild.To understand to what extent and why they are vulnerable.

4

Previous research and our motivationA “formalized model”

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.

Challenge in analysis of real-world SSO

Browser

RPIdP

Invisible to us

Vulnerabilities reported in this paperSSO scheme Logic flaw Affected Sites

Google (OpenID in general)

Email authenticity Smartsheet, Zoho, Yahoo! Mail, etc.

Facebook Flash cross domain All RPs

Janrain Whitelist bypass through xdReceiver All RPs

Facebook, Janrain Automatic linking Freelancer, Nasdaq, NYSenate, etc.

Google, PayPal (OpenID in general)

Data type confusion toms.com, shopgecko.com

Janrain Whitelist bypass through redirection Sears.com

Facebook Signature validation FarmVille

Facebook Anonymous visit Zoho.com

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

Two equivalent views of browser traffic: round trips vs. BRMs

8

Browser relayed message (BRM)

IdP RP

browser

1a1b2a2b

3a3b

A round trip = a browser request + its response

IdP RP

browser

1a

BRM1BRM2

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&…

An example BRM

src=a.com dst=Facebook.com/foo.phpSet-cookies: sessionID=6739485Arguments: x=123 & user=johnCookies: fbs=a1b2c3 & foo=43da2c2a

10

Adversary scenarios

There are four “SSO triangles”Alice-IdP-Bob, Bob-IdP-RP, Alice-IdP-RP and Alice-Bob-RPWe do not consider Alice-Bob-RP, which would require Bob to act as an IdP

When Bob is involved

RPIdP

Alice’s browser

Bob

The three adversary scenarios corresponding to three SSO triangles

(A) Bob as a client (B) Bob as another relying party

IdP RP IdP RP

(C) Bob as a parasite page in Alice’s browser

IdP RP

13

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 analyzerCollect three traffic traces. (An example trace)Submit them to the BRM analyzerThe 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.

The BRM analyzer

15

Studied cases and findings

Deployment of Google ID

Google ID is based on OpenID.

Abstract trace for scenario (A) is shown here.

Important elementsOpenid.ext1.required in BRM1Openid.sig in BRM3Openid.signed in BRM3Openid.ext1.required is propagate to Openid.signed

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/authArguments: st[MU][SEC]

BRM3: src=!IdP dst=https://RP/b/openidArguments: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

Alice’s browser

Deployment of Google ID (cont.)

Google ID service

Relying party website

BRM1: realm= the RP’s identityrequired=(email,firstname,lastname)

BRM3: signed=(email,firstname,lastname)email=“alice@a.com”firstname=“Alice”lastname=“Smith”signature=“HRU436ETQ95TR939”

A simplified illustration of the SSO scheme

(BRM2: unimportant, ignored in this talk)

Relying party websiteGoogle ID

service

Bob’s browser

The attack

BRM1: realm= the RP’s domainrequired=(email,firstname,lastname)

BRM1: realm= the RP’s domainrequired=(email,firstname,lastname)

BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson”email=“alice@a.com”

Google’s signature verified.Welcome, user “alice@a.com”!

Reality: many RP websites use email address to identify users.Suppose Bob knows Alice’s email address.

BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson”

Google’s signature correct ≠ All data on the message verified

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 RPNow, Bob would be able to login to the target RP.

Does this obvious attack work?

BRM1:src=Bob.com dst=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 )

BRM2:src=!IdP dst=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 )

Hi Facebook, I am NYTimes.com

Facebook generates result to allow login

to NYTimes.com

result is passed to Bob.com

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 scenarioBoth 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)

How Facebook SSO really works

http://bob.com

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.

The vulnerability

Unpredictable

domain comm.

Impact

Acknowledgements from many companies

Security advisories published

News coverage

any many others

23

Lessons learned

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 systemsThe flaws are hard to foresee before we examine concrete deployment cases

Understanding system details vs. logic reasoning

Real-world integration is through APIs. Through integrating web APIs, SDKs and sample code offered by ID providersA 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.

25

protocols vs. real systems

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.

26

Conclusions

Martín AbadiManuel Caballero Alex HaldermanCormac Herley Zhou LiShaz QadeerDavid RossNik Swamy Helen Wang Yi-Min Wang

27

Acknowledgement

Visit http://sso-analysis.org