signing me onto your accounts through facebook and google: a traffic-guided security study of...
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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=“[email protected]”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=“[email protected]”
Google’s signature verified.Welcome, user “[email protected]”!
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.
ImpactAcknowledgements 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