Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization

1. In Usenix Security 2013 Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization Rui Wang, Yuchen Zhou, Shuo Chen, ShazQadeer, David Evans, Yuri Gurevich

2. 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 • …

3. Single Sign-On Identity Provider (IDP) • Functionality provided by Token • Authentication: Authenticate end user to SP • Authorization: SP can access user’s social data on IDP Uname/passwrod e.g., Token Alice Token Service Provider (SP) e.g.,

4. Development Paradigm IDP Development SDK-Client SDK-Server SP Client: FooAppc Server:foo.com Deployment

5. 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!

6. A real example: use of Microsoft Live ID ✓ • Goal of this paper • To systematically identify the assumptions required to use an SDK to produce secure applications The attacker can request a token to view public information for the victim and present it to App server. ✗

7. Approach Overview Semantic Model

8. 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

9. Outline • Threat Model & Security Properties • Semantic Modeling • Modeling language • Modeling adversary • Modeling concrete modules • Results

10. Threat Model • Malicious application • Unconstrained behavior • Only limited to functionality provided by client runtime • Unconstrained external server

11. 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)

12. 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

13. Modeling SDKs --- Rewrite PHP Boogie

14. 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

15. 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

16. 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

17. 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 sessionID.

18. Case Study #1: session hijacking Session Variables: _SESSION[‘sessionid’] = 0x01 Token FooAppS Alice

19. How FooAppS handles the token? Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice

20. Case Study: session hijacking Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice 0x02 Token FooAppS Alice Session Variables: _SESSION[‘sessionid’] = 0x02

21. Attack Using Subdomains • Facebook’s developer portal : Heroku • Each service app runs in a subdomain under heroku.com Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice 0x02 FooApp.heroku.com Alice Set cookie: sessionid = 0x02 MalApp.heroku.com

22. Case Study #2: Wrong Association Attacker’s valid signed request Session Variables: _SESSION[‘access_token’] = 0xabc _SESSION[‘user_id’] = Alice Attacker

23. Case Study #3: token leakage http://facebook.com/logout.html?......&access_token =ao231rusd… getAccessToken()

24. getAccessToken() Secret shared between FB and App Secret shared among FB, user and App http://facebook.com/logout.html?......&access_token =ao231rusd…

25. Conclusion • This paper uses formal methods to identify the underlying security assumptions form web authentication/authorization. • Security of implementations relies on multiple underlying assumptions.

26. Thank you!