Slides - NUS Security Research

advertisement
In Usenix Security 2013
Explicating SDKs:
Uncovering Assumptions Underlying
Secure Authentication and Authorization
Rui Wang, Yuchen Zhou, Shuo Chen,
Shaz Qadeer, David Evans, Yuri Gurevich
Web Authentication & Single Sign-On
• Web Authentication
• Single Sign-On (SSO)
– BrowserID (Mozilla)
– Facebook Connect
• 250+ Million users, 2,000,000
websites
– OpenID
• one billion users, 50,000 websites
–…
2
Single Sign-On
Identity Provider (IDP)
e.g.,
Alice
Service Provider (SP)
e.g.,
• Functionality provided by Token
– Authentication: Authenticate end user to SP
– Authorization: SP can access user’s social data on IDP
Development
Development Paradigm
IDP
SDK-Client
SP
Client: FooAppc
Deployment
SDK-Server
Server:foo.com
Motivation
• Security relies on:
– SDKs
– Underlying system
– Implicit assumptions
• undocumented
• SDK providers are unaware of them
If developers use the SDKs in a reasonable ways, will the resulting
applications be secure?
NO!
A real example: use of Microsoft Live ID
✓
✗
The attacker can request a token
to view public information for
the victim and present it to App
server.
• Goal of this paper
– To systematically identify the assumptions required to use
an SDK to produce secure applications
Approach Overview
Semantic
Model
Results
• Test three sets of applications using major
authentication/authorization SDKs
– Facebook PHP SDK, Miscrosoft Live Connect, Windows 8
Authentication Broker SDK
– 78%, 86%, 67% are vulnerable
– Lead to modification of OAuth 2.0 specification
Outline
• Threat Model & Security Properties
• Semantic Modeling
– Modeling language
– Modeling adversary
– Modeling concrete modules
• Results
Threat Model
• Malicious application
– Unconstrained behavior
– Only limited to functionality provided by client
runtime
• Unconstrained external server
Security Properties
• Secrecy
– Access tokens, codes, app secret, session ID
• Authentication
– Attacker may impersonate as victim
• Authorization
– Attacker can do whatever the FooApp can do on the IDP
• Association
– (user’s ID, user’s permission, session’s ID)
Model Checker & Modeling Language
• Corral
– Performs bounded verification on a C program with
embedded assertions
– Explores all possible execution path to check whether the
assertions can be violated
• Boogie language
– ASSERT(p): whenever the program gets to this line, p holds
– ASSUME(p): assume p holds whenever the program gets
to this line
– INVARIANT(p): p always holds
– If Boogie fails to prove an assertion or an invariant, it
reports a counter example
Modeling SDKs --- Rewrite
PHP
Boogie
Modeling Underlying Systems
• IDP’s behaviors according to different input
– Challenge: no source code
– Solution: fuzzing
• Data processing on client runtime
– 1. data redirection from one server to another
– 2. delivering data to FooAppc
– 3. attaching cookies to outgoing request
• Session, request and cookies on the server side
Modeling Security Properties---Authentication
An authentication violation occurs when an attacker acquires
some knowledge that could be used to convince FooAppS that
the knowledge holder is Alice.
• Whenever an attacker acquires a knowledge k
Modeling Security Properties---Authorization
An authorization violation occurs when an attacker acquires
some permission that allows him to do whatever the session
can do.
• Whenever an attacker acquires a Code c
Asserts that Code c is not associated with Alice on FooApp
Modeling Security Properties---Association
At the return point of every web API on FooAppS, we need to
ensure the correct association of the user ID, the permission, and
the session ID.
Case Study #1: session hijacking
Session Variables:
_SESSION[‘sessionid’] = 0x01
Alice
Token
FooAppS
How FooAppS handles the token?
Session Variables:
_SESSION[‘sessionid’] = 0x01
_SESSION[‘user_id’] = Alice
Case Study: session hijacking
Session Variables:
_SESSION[‘sessionid’] = 0x01
0x02
_SESSION[‘user_id’] = Alice
Alice
Token
FooAppS
Session Variables:
_SESSION[‘sessionid’] = 0x02
Attack Using Subdomains
• Facebook’s developer portal : Heroku
– Each service app runs in a subdomain under heroku.com
Session Variables:
_SESSION[‘sessionid’] = 0x01
0x02
_SESSION[‘user_id’] = Alice
Alice
FooApp.heroku.com
MalApp.heroku.com
Case Study #2: Wrong Association
Attacker’s valid signed request
Session Variables:
_SESSION[‘access_token’] = 0xabc
_SESSION[‘user_id’] = Alice
Attacker
Case Study #3: token leakage
http://facebook.com/logout.html?......&access_token =ao231rusd…
getAccessToken()
getAccessToken()
Secret shared between
FB and App
Secret shared among FB,
user and App
http://facebook.com/logout.html?......&access_token =ao231rusd…
Conclusion
• This paper uses formal methods to identify the
underlying security assumptions form web
authentication/authorization.
• Security of implementations relies on multiple
underlying assumptions.
Thank you!
Download
Related flashcards

Computer security

25 cards

Free backup software

28 cards

Backup software

62 cards

Malware in fiction

20 cards

Create Flashcards