seclab Impersonation Attacks through a Dedicated Bi-directional - - PowerPoint PPT Presentation

▶
seclab
SMART_READER_LITE
LIVE PREVIEW

seclab Impersonation Attacks through a Dedicated Bi-directional - - PowerPoint PPT Presentation

May 31, 2023 242 likes •706 views

Protecting Web-based Single Sign-on Protocols against Relying Party seclab Impersonation Attacks through a Dedicated Bi-directional Authenticated Channel THE COMPUTER SECURITY GROUP AT UC SANTA BARBARA Yinzhi Cao

slide-1
SLIDE 1

Protecting Web-based Single Sign-on Protocols against Relying Party Impersonation Attacks through a Dedicated Bi-directional Authenticated Channel Yinzhi Cao Yan Shoshitaishvili Kevin Borgolte Christopher Kruegel Giovanni Vigna Yan Chen

seclab

THE COMPUTER SECURITY GROUP AT UC SANTA BARBARA

University of California, Santa Barbara Northwestern University

  • September 17th, 2014
  • RAID 2014 — Authentication & Privacy

yinzhi.cao@eecs.northwestern.edu yans@cs.ucsb.edu kevinbo@cs.ucsb.edu chris@cs.ucsb.edu vigna@cs.ucsb.edu ychen@cs.northwestern.edu

slide-2
SLIDE 2

Roadmap

  • Single Sign-on
  • Threat Model
  • Problems with Existing Designs
  • Our Design
  • Evaluation

2

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-3
SLIDE 3

Single Sign-on (SSO) (1)

  • Idea: log in to a website with your Facebook,

Google, etc. account

3

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-4
SLIDE 4

Single Sign-on (SSO) (1)

  • Idea: log in to a website with your Facebook,

Google, etc. account

3

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-5
SLIDE 5

Single Sign-on (SSO) (1)

  • Idea: log in to a website with your Facebook,

Google, etc. account

3

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-6
SLIDE 6

Single Sign-on (SSO) (1)

  • Idea: log in to a website with your Facebook,

Google, etc. account

3

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-7
SLIDE 7

Single Sign-on (SSO) (1)

  • Idea: log in to a website with your Facebook,

Google, etc. account

3

seclab

Kevin Borgolte WebSSO - Protecting SSO against RPI Attacks

slide-8
SLIDE 8

Single Sign-on (SSO) (2)

4

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

Image by Mutually Human, via http://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/.

slide-9
SLIDE 9

Problems

  • SSO vulnerabilities mean
  • User impersonation
  • Data/privacy leaks


5

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-10
SLIDE 10

Problems

  • SSO vulnerabilities mean
  • User impersonation
  • Data/privacy leaks

  • Vulnerabilities are prolific
  • Wang et al. identified five vulnerabilities in which an

attacker can impersonate a user [Oakland ’12].

  • Sun et al. show that 6.5% of relying parties are

vulnerable to impersonation attacks [CCS ’12].

5

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-11
SLIDE 11
  • Identity provider (IdP)
  • A centralized identification service
  • Trusted and benign

  • Relying party (RP)
  • A third party using the IdP to authenticate users
  • Potentially malicious

  • User
  • Wants to use the RP’s service
  • Trusted and benign

Threat Model - Concepts

6

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-12
SLIDE 12

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-13
SLIDE 13
  • In-scope
  • Benign RP initiates request, malicious RP receives response

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-14
SLIDE 14
  • In-scope
  • Benign RP initiates request, malicious RP receives response

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

GET https://www.idp.com/login? app_id=****&redirection_url=https://www.idp.com/granter? next_url=https://www.rp.com/login

  • Host: www.idp.com
  • Referer: https://www.rp.com/login
  • Cookie: ****
slide-15
SLIDE 15
  • In-scope
  • Benign RP initiates request, malicious RP receives response

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

GET https://www.idp.com/login? app_id=****&redirection_url=https://www.idp.com/granter? next_url=https://www.rp.com/login

  • Host: www.idp.com
  • Referer: https://www.rp.com/login
  • Cookie: ****
slide-16
SLIDE 16
  • In-scope
  • Benign RP initiates request, malicious RP receives response
  • Malicious RP initiates the attack

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

GET https://www.idp.com/login? app_id=****&redirection_url=https://www.idp.com/granter? next_url=https://www.rp.com/login

  • Host: www.idp.com
  • Referer: https://www.rp.com/login
  • Cookie: ****
slide-17
SLIDE 17
  • In-scope
  • Benign RP initiates request, malicious RP receives response
  • Malicious RP initiates the attack

Threat Model - Attacks (1)

7

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

⇒ Information leakage or user impersonation!

slide-18
SLIDE 18
  • Out-of-scope
  • Social engineering
  • Compromised or vulnerable RP
  • Malicious user (browser)
  • Implementation issues
  • Privacy leaks

Threat Model - Attacks (2)

8

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-19
SLIDE 19

Revisit - Identities

9

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

  • Existing identities
  • IdP, usually web origin (<scheme, host, port>)
  • RP, unique identifier, depending on protocol,

app_id or AppName

  • User, unique identifier like username or email

address

slide-20
SLIDE 20

Revisit - Identities

9

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

  • Existing identities
  • IdP, usually web origin (<scheme, host, port>)
  • RP, unique identifier, depending on protocol,

app_id or AppName

  • User, unique identifier like username or email

address

Main issue: RP identifier can be forged.

slide-21
SLIDE 21

Revisit - Communication

10

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

  • Communication between RP and IdP
slide-22
SLIDE 22

Revisit - Communication

10

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

  • Communication between RP and IdP
  • HTTP(s) redirection to 3rd party server (1-way channel)
slide-23
SLIDE 23

Revisit - Communication

10

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

  • Communication between RP and IdP
  • HTTP(s) redirection to 3rd party server (1-way channel)
  • In-browser communication channel (no authentication)
slide-24
SLIDE 24
  • Clean-slate design, replaces existing protocols
  • Identity
  • Web origin for RP and IdP: <scheme, host, port>
  • Communication channel
  • Dedicated
  • Bi-directional
  • Authenticated
  • Secure

Identity Provider Deployment (1)

11

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-25
SLIDE 25
  • Establishing the channel: handshake

Identity Provider Deployment (2)

12

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-26
SLIDE 26
  • Establishing the channel: handshake
  • Sending messages

Identity Provider Deployment (2)

12

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-27
SLIDE 27
  • Establishing the channel: handshake
  • Sending messages
  • Receiving messages

Identity Provider Deployment (2)

12

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-28
SLIDE 28
  • Establishing the channel: handshake
  • Sending messages
  • Receiving messages
  • Terminating the connection: releasing resources

Identity Provider Deployment (2)

12

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-29
SLIDE 29
  • Allows smooth transition to more secure protocol
  • Does not require you to replace existing protocol
  • Proxy communicates with legacy IdP
  • RPs communicate with proxy

Relying Party / Proxy Deployment

13

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-30
SLIDE 30
  • Allows smooth transition to more secure protocol
  • Does not require you to replace existing protocol
  • Proxy communicates with legacy IdP
  • RPs communicate with proxy

Relying Party / Proxy Deployment

13

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-31
SLIDE 31
  • Prototype implementation
  • Clean-slate / IdP deployment
  • Two protocols: OpenID-like and OAuth-like
  • 252 LOC JavaScript, 264 LOC HTML, 243 LOC PHP
  • External libraries: JavaScript Cryptography Toolkit +

Stanford JavaScript Crypto Library

  • Proxy / RP deployment
  • Based on a Facebook application

Implementation

14

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-32
SLIDE 32
  • Formally verified design with ProVerif
  • Channel verification
  • Attacker: passive (sniffing), active (sending messages)
  • Result: an attacker cannot obtain the plain text message
  • Protocol verification
  • Attacker: network (passive) and web attackers (active)
  • Result: an attacker cannot obtain any useful information
  • Proxy verification
  • Attacker: passive (sniffing), active (sending messages)
  • Result: an attacker can obtain and modify the messages sent over

the insecure communication channel between proxy and legacy IdP

Evaluation - Formal Verification

15

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-33
SLIDE 33
  • Our protocol prevents all impersonation attacks

identified by Wang et al. [Oakland ’12]:

  • Facebook and New York Times
  • Facebook and Zoho
  • Facebook Legacy Canvas Auth
  • JanRain wrapping GoogleID
  • JanRain wrapping Facebook

Evaluation - Security Analysis

16

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-34
SLIDE 34

Channel operation

Evaluation - Performance

17

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

Operation Delay [ms]

Establishing the channel 164±12 Sending a message 32±2 Destroying a channel 70±3

slide-35
SLIDE 35

Channel operation

Evaluation - Performance

17

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

Operation Delay [ms]

Establishing the channel 164±12 Sending a message 32±2 Destroying a channel 70±3

Establishing the channel

Operation Delay [ms]

Message #1: PK_RP 92±9 Message #2: PK_RP(SK, N_IdP) 29±2 Message #3: SK(N_RP) 43±3

slide-36
SLIDE 36

Detailed breakdown of the protocol

Evaluation - Performance

18

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

Operation Delay [ms]

(1) Creating the channel between RP and IdP 164±11 (2) Creating the IdP inline frame 57±3 (3) Sending the first message from RP to IdP 32±2 (4) Creating the IdP inline frame for authentication 57±3 (5) Creating the second channel inside the IdP 165±11 (6) Authenticating the user 56±4 (7) Requesting the user’s permissions 57±3 (8) Sending the token inside the IdP’s inline frame 32±2 (9) Sending the token to the RP 33±2

Total 653±21

(2), (4), (6), and (7) are dominated by network latency, which is 50ms here.

slide-37
SLIDE 37
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-38
SLIDE 38
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

  • Proposed a dedicated bi-directional secure

channel to remedy existing short-comings

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-39
SLIDE 39
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

  • Proposed a dedicated bi-directional secure

channel to remedy existing short-comings

  • Designed SSO protocol on top of channel design

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-40
SLIDE 40
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

  • Proposed a dedicated bi-directional secure

channel to remedy existing short-comings

  • Designed SSO protocol on top of channel design
  • Presented a proxy design for easy adoptability

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-41
SLIDE 41
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

  • Proposed a dedicated bi-directional secure

channel to remedy existing short-comings

  • Designed SSO protocol on top of channel design
  • Presented a proxy design for easy adoptability
  • Formally verified security of the SSO protocol

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-42
SLIDE 42
  • Pointed out root cause why RPI attacks exist:


non-dedicated, insecure, one-way channel between RP and IdP

  • Proposed a dedicated bi-directional secure

channel to remedy existing short-comings

  • Designed SSO protocol on top of channel design
  • Presented a proxy design for easy adoptability
  • Formally verified security of the SSO protocol
  • Evaluated protocol performance / overhead

Conclusion

19

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

slide-43
SLIDE 43

kevin@borgolte.me http://kevin.borgolte.me twitter: @caovc

Thank you for your attention!

seclab

THE COMPUTER SECURITY GROUP AT UC SANTA BARBARA

slide-44
SLIDE 44

kevin@borgolte.me http://kevin.borgolte.me twitter: @caovc

Thank you for your attention! Questions?

seclab

THE COMPUTER SECURITY GROUP AT UC SANTA BARBARA

slide-45
SLIDE 45

Related Work

21

seclab

Kevin Borgolte WebSSO - Protecting Web-based SSO against RPI Attacks

Deployment Protection Crowd Preventing Impersonation Attacks Proactive Deployment

InteGuard IdP, Gateway IdP Users, 
 physical machines AuthScan IdP IdP Users Explicating SDKs IdP IdP Users Defensive JavaScript IdP, RP IdP Users,
 RP Users WebSSO
 (our work) IdP, RP IdP Users,
 RP Users