/
Matthew Van Gundy Technical Leader, Cisco Advanced Security Initiatives Group (ASIG) Matthew Van Gundy Technical Leader, Cisco Advanced Security Initiatives Group (ASIG)

Matthew Van Gundy Technical Leader, Cisco Advanced Security Initiatives Group (ASIG) - PowerPoint Presentation

pressio
pressio . @pressio
Follow
347 views
Uploaded On 2020-06-24

Matthew Van Gundy Technical Leader, Cisco Advanced Security Initiatives Group (ASIG) - PPT Presentation

Cisco Offensive Summit 2018 Finding and exploiting common OAuth pitfalls SSnOnos gcal gcal gcal Whats the point of this OAuth stuff anyway gcal gcal ID: 786389

client redirect state uri redirect client uri state cisco code token post attacker authorize access https oauth api scope

Share:

Link:

Embed:

Download Presentation from below link

Download The PPT/PDF document "Matthew Van Gundy Technical Leader, Cisc..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Matthew Van Gundy

Technical Leader, Cisco Advanced Security Initiatives Group (ASIG)

Cisco Offensive Summit 2018

Finding and exploiting common OAuth pitfalls

SSnO-nos

Slide2

Slide3

@

(gcal)

@

(gcal)

@

(gcal)

What’s the point of this OAuth stuff anyway?

@

@

@

@

(gcal)

@

@

(gcal)

@

(gcal)

User

Client

Authorization

Server

Protected

Resource

Protected

Resource

Adversary

Slide4

OAuth 2.0 Authorization

POST /token

code, client_id, client_secret, redirect_uri

access_token

GET /resource Auth…n: ...

access_token

resource

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code

,

state

POST cisco/authorize username, password

GET cisco/authorize

client_id, redirect_uri, state, scope

Redirect cisco/authorize client_id, redirect_uri, state, scope

POST /start

alice@cisco

session_cookie

Google Calendar

Slide5

SSO w/ OAuth 2.0

POST /token

code, client_id, client_secret, redirect_uri

access_token

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code

,

state

POST cisco/authorize

username, password

GET cisco/authorize

client_id, redirect_uri, state, scope

Redirect cisco/authorize client_id, redirect_uri, state, scope

POST /start alice@cisco

session_cookie

GET /resource Auth…n: ...

access_token

GET /identity Auth…n: ...

access_token

resource

user_id, client_id

Slide6

Pitfalls of Client implementations

Slide7

Transport Encryption?

POST /token

code, client_id, client_secret, redirect_uri

access_token

GET /resource Auth…n: ...

access_token

resource

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code

,

state

POST cisco/authorize username, password

GET cisco/authorize

client_id, redirect_uri, state, scope

Redirect cisco/authorize client_id, redirect_uri, state, scope

POST /start

alice@cisco

session_cookie

Do all endpoints employ TLS and HTTP Strict Transport Security?

Slide8

Force-Login CSRF

POST /token

code, client_id, client_secret, redirect_uri

access_token

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code

,

state

GET cisco/authorize

client_id, redirect_uri, state, scope

Redirect cisco/authorize

client_id, redirect_uri, state, scope

POST /start alice@cisco

<form action=“spark/start”>…</form>

TOFU

GET /identity Auth…n: ...

access_token

user_id, client_id

session_cookie

<form action=“spark/spaces/add”>…</form>

session_cookie

POST /spaces/add

attacker to “Quarterly Earnings”

Do login pages prevent CSRF?

Slide9

Session Swapping

(aka Client Callback CSRF)

GET

redirect_uri

code

,

state

POST /token

code, client_id, client_secret, redirect_uri

access_token

Redirect:

redirect_uri

?

code

,

state

Redirect cisco/authorize

client_id, …, state

POST /start attacker@cisco

Redirect:

redirect_uri

?

code, state

POST ...

access_token

Is state a

fresh random nonce

?

Does Client validate state against User session upon call to redirect_uri

?

Slide10

state = SHA2(session_cookie);

Does not change on each OAuth flow!

Can a CSRF Token Make a Good state Value?

r = new SecureRandom();

state = new BigInteger(130, r).toString(32);

state = csrf_token();

Does not change on each OAuth flow!

Slide11

state Leak

POST /start

alice@cisco

GET ...

access_token

access_token

GET

redirect_uri

code’

,

state

Redirect:

redirect_uri

?

code’

,

state

Get OAuth

code’

GET /branding Referer:

redirect_uri

?

code, state

<img src=attacker/branding>

access_token

POST /token

code, …

GET

redirect_uri

code

,

state

POST /token code’, …

Is state single-use?

Slide12

redirect_uri Manipulation

GET

https://attacker

?

code

,

state

POST /token

code, client_id, client_secret, redirect_uri

access_token

POST /start

alice@cisco

Redirect:

https://attacker

?

code

,

state

GET cisco/authorize client_id,

https://attacker, state, scope

Redirect cisco/authorize client_id, https://attacker, state, scope

TOFU

Redirect cisco/authorize client_id, redirect_uri, state, scope

GET

redirect_uri code

,

state

session_cookie

valid_redirect?(

client_id

,

https://attacker

)

redirect_uri == https://attacker

if grant.type == IMPLICIT then game_over()

elsif client.type == PUBLIC then game_over()else ????

Slide13

Subdirectory Validation:

https://client.com/api/oauth/callbackhttps://client.com/api/profiles/attacker

https://attacker.client.com/api

http://client.com/apiSubdomain Validation:

https://client.com/api/oauth/callback

https://client.com/api/profiles/attacker

https://attacker.client.com/api

http://client.com/api

redirect_uri Validation

Registered redirect_uri: https://client.com/api

Slide14

Over-broad redirect_uri

GET

https://client/api/u/attacker

?

code

,

state

POST /token

code, client_id,

client_secret

,

https://client/api/u/attacker

access_token

POST /start

alice@cisco

Redirect:

https://client/api/u/attacker

? code, state

GET cisco/authorize client_id,

https://client/api/u/attacker, state, scope

Redirect cisco/authorize client_id, https://client/api/u/attacker, state, scope

Redirect cisco/authorize

client_id, redirect_uri, state, scope

Registered redirect_uri: https://client/api

subdir?

GET /badge.png Referer:

https://client/api/u/attacker

?code, state

TOFU

<img src=attacker/badge.png>

redirect_uri ==?

Are

full

redirect_uris registered?Is separate leaf subdomain used for redirect_uris

?Do Public Clients using Dynamic Client Registration?

Slide15

IdP Mix-Up (Authentication)

POST /token

code, client_id’, client_secret’, redirect_uri

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code

,

state

GET cisco/authorize client_id, redirect_uri, state, …

Redirect cisco/authorize client_id, redirect_uri, state, …

Redirect attacker/authorize

client_id’, redirect_uri, state, …

POST /start alice@attacker

POST /start

alice@cisco

: auth_server:

attacker

TOFU

Slide16

IdP Mix-Up (Authentication)

POST /token

code, client_id’, client_secret’, redirect_uri

Redirect cisco/

authorize

client_id’, redirect_uri, state’, …

POST /start

alice@

cisco

: auth_server:

cisco

Does

Client use HSTS?

Does

Client

register a unique

redirect_uri

with each Authorization Server (unique-prefix paths, separate subdomain)?

Does Client require that Authorization Responses are received on correct

redirect_uri?

GET

redirect_uri

code, state’

POST /token

code, client_id, client_secret, redirect_uri

access_token

Slide17

IdP Mix-Up (Authorization)

resource

GET /resource Auth…n: ...

access_token

access_token

POST /token

code, client_id, client_secret, redirect_uri

POST /token

code, client_id’, client_secret’, redirect_uri

GET

redirect_uri

code

,

state

Redirect:

redirect_uri

?

code, state

GET cisco/authorize client_id, redirect_uri, state, …

Redirect cisco/authorize

client_id, redirect_uri, state, …

Redirect attacker/authorize client_id’, redirect_uri, state, …

POST /start

alice@attacker

POST /start

alice@cisco

: auth_server:

attacker

TOFU

Does

Client use HSTS?

Does

Client

register a unique redirect_uri with each Authorization Server (unique-prefix paths, separate subdomain)?

Does Client require that Authorization Responses are received on correct redirect_uri?

Slide18

Guidance

Attack

Employ TLS and HSTS for all endpoints

Sniffing, IdP Mix-Up

Provide CSRF protection for login pages

Force-Login CSRF

Use fresh random nonce for OAuth Client

state

variable, validate state upon call to

redirect_uri

Client callback

Session Swapping

(Client Callback CSRF)Client

state variable must be single-usestate LeakRegister full redirect_urisredirect_uri ManipulationUse separate subdomain for

redirect_urisredirect_uri ManipulationPrefer dynamic Client registration over public Clientsredirect_uri Manipulation

Register a unique redirect_uri with each Authorization ServerIdP Mix-UpRequire that Authorization Responses received redirect_uri of User-selected Authorization ServerIdP Mix-Up

Keep access_token lifetimes shortToken LeakCollected Recommendations & Attacks

Slide19

OAuth 2 in Action by Justin Richer Antonio Sanso

The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems by S. Sun and K. Beznosov. CCS 2012A Comprehensive Formal Security Analysis of OAuth 2.0 by D. Fett, R. Küsters, and G. Schmitz. CCS 2016

OAuth 2.0 Mix-Up Mitigation by M. Jones, J. Bradley, and N. Sakimura. draft-ietf-oauth-mix-up-mitigation-01RFC 6749: The OAuth 2.0 Authorization Framework. D. Hardt, Ed.

References

Slide20

Your questions here:

_____________________

Slide21