Catching Pitfalls in Authentication Implementations (Yuchen Zhou)

997 views
898 views

Published on

Guest lecture by Yuchen Zhou
http://www.rust-class.org

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
997
On SlideShare
0
From Embeds
0
Number of Embeds
212
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Catching Pitfalls in Authentication Implementations (Yuchen Zhou)

  1. 1. Catching Pitfalls in Authentication Implementations Yuchen Zhou (filling in for Prof. David Evans)
  2. 2. Outline • Authentication, SSL review • Single Sign-On protocol • (Part of) My research
  3. 3. Checks the factors multiply to produce n Problems with this? 29 October 2013 University of Virginia cs4414 3
  4. 4. Authentication (review)
  5. 5. Checks that D(x)e mod n = x I give you x, you give me D(x) So that D(x)e mod n = x What is the public key? Private key? 29 October 2013 University of Virginia cs4414 5
  6. 6. SSL (Secure Sockets Layer) Simplified TLS Handshake Protocol Client Verify Certificate using KUCA Check identity matches URL Generate random K Hello Server KRCA[Server Identity, KUS] After the handshake, client has KRCA[Server Identity, KUS], what prevents client from reusing this EKUS (K) and impersonating the server? Decrypt using KRS Secure channel using K 29 October 2013 University of Virginia cs4414 6
  7. 7. SSL (Secure Sockets Layer) Simplified TLS Handshake Protocol Client Verify Certificate using KUCA Check identity matches URL Generate random K Server Hello KRCA[Server Identity, KUS] The client won’t have KRS, and won’t be able to decrypt for K. EKUS (K) Decrypt using KRS Secure channel using K 29 October 2013 University of Virginia cs4414 7
  8. 8. OK, now onto some new stuff…
  9. 9. Single Sign-On (SSO) Service 9
  10. 10. Single Sign-On (SSO) Service Involves Three parties: • Identity provider • Relying party • User
  11. 11. OAuth and Single Sign-On Major identity providers (IdP) use OAuth as SSO protocol – 2.0 is the most popular version OAuth specification describes what interface IdPs should provide, and what practice the RP must follow.
  12. 12. A typical OAuth authentication workflow Relying Party (e.g., espn.com) User (Web Client) Identity Provider (e.g., Facebook) Visit Redirect Login Permission granting OAuth Credentials OAuth Credentials Confirm credentials Authenticated Verify login and issue credentials
  13. 13. But this is hard to get right!
  14. 14. SSO SDKs No worries, IdP SDK came to the rescue!
  15. 15. But this is (still) hard to get right! Even if the developers follow the guides properly, the application could still be insecure!
  16. 16. The requested response type, one of code or token. Defaults to code… Facebook documentation example 16
  17. 17. Possible implementation response_type = access_token Foo App Client Facebook back end 3 access_token 6 Welcome, Alice! Foo App Server 17
  18. 18. Access_token CAADxRthhGccBAFtpBpZAyg80NH6defOZCZAiRP AMCUmxlN3nw5ZBfQIK7YZAtKbCBYszbwZAsjLRb vP3CI2W0U0eXLaQhehZCEOu2LF7RzqxiVCGvTiA ZCJ4ZCk5CxILfF2QKfSlsUXJ22y0dtJdA8MQO
  19. 19. Exchange User information Request: https://graph.facebook.com/me?access_token=CAADxRt hhGccBAFtpBpZAyg80NH6defOZCZAiRPAMCUmxlN3nw5Z BfQIK7YZAtKbCBYszbwZAsjLRbvP3CI2W0U0eXLaQhehZCE Ou2LF7RzqxiVCGvTiAZCJ4ZCk5CxILfF2QKfSlsUXJ22y0dtJd A8MQO User’s FB ID Response: { "id": "100006071110883", "name": "Syxvq Ldfwpk", "first_name": "Syxvq", "last_name": "Ldfwpk", "link": "https://www.facebook.com/syxvq.ldfwpk", "username": "syxvq.ldfwpk“….}
  20. 20. Possible implementation Possible Attack response_type = access_token Malicious Foo App App Client Client 3 access_token Facebook back end 3 access_token 6 Welcome, Alice! 4 access_token Foo App Server 7 Welcome Alice?! 20
  21. 21. Signed_request to the rescue! c47YUduADVDyJs4yV6Lvq2V0yxPxSX_rJbzzhICFRQ.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUi OiJBUUIwRGpVaW1TREpRcFdTY3M0Yk1rX2tZNU41SFBhZTZqV Signature mNEdVdpM2ktc1VJaHN4RmtHR2tneEU3UFFVYVBtbXdUV2dz QWg5QUI1RmFzeXVOZkt3NGpGMDE3ZGY2WEEyazB6M3Q2az NYYjFDVGJXQzZJZEtoaDdsRnp4TTExZm8tWGdYblZXbUxibU1f MmJHWDhFVWlxQk1ybVpweUxTUzI0TUw0ZnB6WmhRZjU5Sz U4bkY4LS1yT3M3QVI4RG0xb0xaeDduQkRiQVl4bmVqcnhOc0x LZTB2UFhBb2JXaTVHNkxfOU1JS192alg2anZUSzlCcDItbEMyem dveFNFb01BU2g0NzFqUnMwd2JzT29HUW1ZVDVndGRFaWcx NzZMYkt1Q1ZqMDd1a2ZFejlEdU1wX09xSDFIVWFPWlRVNjlw NFZnbVh0Ql9NVzQ3YWlmRGJHSTRYVyIsImlzc3VlZF9hdCI6MT M3OTQyNDgxNCwidXNlcl9pZCI6IjEwMDAwMzkyOTkwNjEzNyJ 9 Base64 Encoded, signed by application’s secret key
  22. 22. Signed_request to the rescue! Base64 Decoded {"algorithm":"HMACSHA256","code":"AQB0DjUimSDJQpWScs4bMk_kY5N5HP ae6jVcDuWi3isUIhsxFkGGkgxE7PQUaPmmwTWgsAh9AB5FasyuNfKw4jF 017df6XA2k0z3t6k3Xb1CTbWC6IdKhh7lFzxM11foXgXnVWmLbmM_2bGX8EUiqBMrmZpyLSS24ML4fpzZhQf 59K58nF8-rOs7AR8Dm1oLZx7nBDbAYxnejrxNsLKe0vPXAobWi5G6L_ 9MIK_vjX6jvTK9Bp2lC2zgoxSEoMASh471jRs0wbsOoGQmYT5gtdEig176LbKuC Vj07ukfEz9DuMp_OqH1HUaOZTU69p4VgmXtB_MW47aif DbGI4XW","issued_at":1379424814,"user_id":"10000392 9906137"} User’s FB ID
  23. 23. Signature provides integrity and identity! • Integrity: signed contents cannot be changed without invalidating signature. • Identity: The information is intended for the application which owns this secret. • Both property can be verified by HMACing the content of the message using secret key and compare the result with the signature.
  24. 24. Signed_request to the rescue?? Signed_requests are used, but signature is never checked! Signature is checked, but application ignores user_id fields in the message content!
  25. 25. There could be many more like these…
  26. 26. Goal: Systematically find such pitfalls
  27. 27. Modeling and proofs Everybody likes formal proofs that the system is secure. Program analysis techniques can automatically prove things IF the program is small. Modeling helps simplify a large, complex system to a smaller code base that can be formally verified using program analysis techniques.
  28. 28. Modeling: Analogy Proving the entire car never blows up is hard!
  29. 29. Modeling: Analogy Proving the entire engine never blows up is hard!
  30. 30. Modeling Analogy Proving a single fuel injector never blows up is probably easier!
  31. 31. Modeling Advantages • Turn complicated system into simpler systems that are amenable to analysis. Disadvantages • Model behavior does not necessarily agrees with original system. • Abstract away irrelevant details. • Details abstracted away may come back and ‘haunt’ the model. • Reason modules separately, combine smaller proofs to bigger ones. • Complicated interactions between modules might be missed.
  32. 32. Modeling SSO System Mallory Client SDK MalAppC FooAppC FooAppS Service SDK Client runtime Service runtime Identity Provider (IdP) Concrete module with src or documentation Abstract module subject to dev guide Black-box concrete module Abstract module subject to knowledge pool 33
  33. 33. SDK models Facebook PHP Source code Boogie PL Model 34
  34. 34. API models procedure {:inline 1} dialog_oauth(IdPLoggedInUser:User, client_id: AppID, redirect_domain: Web_Domain, scope:Scope, response_type:ResponseType) returns (r:int, Response_data: int) modifies Access_Tokens__TokenValue, Access_Tokens__user_ID, Access_Tokens__Scope; modifies Codes__user_ID,Codes__App_ID,Codes__Scope; modifies … { var access_token:int, code:int, sr:int; … if (response_type==_Token || response_type==_Signed_Request){ havoc access_token; //it means "access_token := *;" … IdP_Signed_Request_signature[sr]:=ValidIdPSignature; IdP_Signed_Request_oauth_token[sr]:=access_token; IdP_Signed_Request_code[sr]:=code; IdP_Signed_Request_user_ID[sr]:= IdPLoggedInUser; IdP_Signed_Request_app_id[sr]:= client_id; } if (response_type==_Token) { Response_data:=access_token; } else if (response_type==_Code) { Response_data:=code; } else { Response_data:=sr; } r:=200; } Facebook Dialog API documentation Boogie model 35
  35. 35. Results overview Explicated three SDKs: (6 months) Many implicit assumptions were found: Facebook SSO PHP SDK 5 cases reported, 4 fixed, 3 bounties (3x). Windows 8 SDK for modern apps One case reported; documentation revised. Windows Live connect SDK Paragraph added to OAuth 2.0 standard. 36
  36. 36. Automatic scanning applications for these vulnerabilities
  37. 37. Goal Large-scale study of how secure Facebook SSO has been implemented in popular websites today. – Need an automatic tool to scan web applications for vulnerabilities.
  38. 38. Misuse Credential leakage • access_token misuse • signed_request misuse • client_secret appears at client side • OAuth credentials leak via referrer header • OAuth credentials leak via DOM content
  39. 39. Approach Web server source/binary not visible from client side. Simulated attacks with traffic and application state monitoring
  40. 40. App driver 41
  41. 41. App driver 42
  42. 42. Oracle Simulated attack result needs to be confirmed – Previous works do this manually, not feasible for massive testing. – To do this automatically, we need to learn visual representation of application states. 43
  43. 43. DEMO time • Ssoscan.org • Pick your favorite site, check if it’s secure.
  44. 44. Evaluation: Dataset Top US 20K sites (Quantcast.com) excluding DNS errors, 4xx/5xx response code. google.com youtube.com facebook.com msn.com amazon.com twitter.com ebay.com pinterest.com yahoo.com bing.com microsoft.com … 45
  45. 45. Results overview 17 913 valid test sites – 1 700 use Facebook SSO • 12% is vulnerable to misuse attacks • 8.5% potentially leaks credentials • 2.3% does not implement Facebook connect correctly Vulnerable 20.3% Timeout/error 7.6% No Facebook SSO, 82.9 % Facebook SSO, 9.5% Valid Top ranked sites (17913) Buggy 2.3% Not Vulnerable 77.4% 1700 Sites using Facebook SSO
  46. 46. Facebook SSO support vs. site ranking 45% % supporting FB SSO 40% 35% 30% 25% 20% 15% 10% 5% 0% 1 10 20 30 40 50 60 Site rank percentile (20K) 70 80 90 100
  47. 47. Misuse vulnerability vs. site ranking 45% 40% % vulnerable 35% 30% 25% 20% 15% 10% 5% 0% 1 10 20 30 40 50 60 Site rank percentile (20K) 70 80 90 100
  48. 48. Trends More popular sites tend to include Facebook SSO more. However, big and popular websites are just as vulnerable as lower-profiled sites.
  49. 49. Credential leakage vs. Site Ranking 45% 40% % vulnerable 35% 30% 25% 20% 15% 10% 5% 0% 1 10 20 30 40 50 60 Site rank percentile (20K) 70 80 90 100
  50. 50. Credential leakage explained OAuth credentials appears in the URL bar http://www.dailymail.co.uk/registration/social/register.html?para m__host=www.dailymail.co.uk&param_code=AQCajy7bQs32zCXg MlcfNMeFA0YhRPN06guZI8doD9AfQJn7IDNUTniVnPiSf7cFVUFs4u_lKpHCmXi4XQ StbLuPN1ur8ynzVY8zqENn3NK3UEK1S0AXeExzlRfUVCbilOler5YImj 2HGak86kGzZcfuby3ATyJsEQTdc1fXmnw_nruVXjjSiNiEKYuyOXQNfAYGDezZZkQe_81agmv7FxcgS9mUspWrnnHLi1nP _9ZpyBU5dUeMTsPV9qXbp3Vs2_3CcMVzd7Sma0s8A1xR-IHD_Y9E96mdT_LKKU8lV_T-ZrphLCwYmj9PXXGZ9wrI#_=_
  51. 51. HTTP response body
  52. 52. Referrer header • • • • • • • • • GET http://tags.crwdcntrl.net/c/991/cc.js?ns=_cc991 HTTP/1.1 Host: tags.crwdcntrl.net User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.dailymail.co.uk/registration/social/register.html?param__host=www.dailymail.co.uk&param_code=A QCajy7bQs32zCXgMlcfNMeFA0YhRPN06guZI8doD9AfQJn7IDNUTniVnPiSf7cFVUFs4u_lKpHCmXi4XQStbLuPN1ur8ynzVY8zqENn3NK3UEK1S0AXeExzl RfUVCbilOler5YImj2HGak86kGzZcfuby3ATyJsEQTdc1fXmnw_nruVXjjSiNiEKYuyOXQNfAYGDezZZkQe_81agmv7FxcgS9mUspWrnnHLi1nP_9ZpyBU5dUeMTsPV9qXbp3Vs2_3CcMVzd7Sm a0s8A1xR-IH-D_Y9E96mdT_LKKU8lV_T-ZrphLCwYmj9PXXGZ9wrI Cookie: _cc_aud="ABR4nCXRzyvDcRzH8fdKO0g7iBbWLhoOXFwpTXEZseVHDqKZmdayi2R%2B9N2UclD7Sn5FODj5C%2FwL WhzERRzMyUp%2BXBzxfH0vj96f9%2Bf9fn8%2Bn6%2BZWWw%2B6zXzhCtPR1GLmPnrHHPMEiXHgmZLvUSpU9g8F 2dCiz23EP2G6RcYv4BkGEY9kP%2BiZ66LaHEXqg9gvcr%2Bv8w92DY7h7zktvJEmRJRn5r5JmCtAs0BqLmGwA%2BM6R DplHY2wOCkChLMWY0Qxa6gvo1BLWVyI41Qe0cucyL2oNipggc9Tzt1Sb3LyqPmvcGCDzqU8w%2FoSJ8UTLmK3mHjG Way5NJlIndfaKyrN3N3oKAuhQ%2BIH7MY0u8I3UCwCWYvIafjtg5DvKg7HEJ%2FNyzrYnOvf%2FwCWZyKIA%3D%3D"; _cc_cc="ACN4nGNQsDRPTTVNMjRNM0mxMEw0MDY1SU42NjY3sEhMM0wyMzRiAIKgzAK2P1t7qxgYGB1f350VCBJj YNt2bQ8jA8spBob%2FjIwMjEC57se1aALXrdAEHn1FE7jlhSrg%2F%2BUxkHG%2FASQAYjA2AIUFuBN2McFEYcpBstwJ O7GKb21pQBi7tWczgrNcThxojSREx7L7uxEcZa63WM3iqm%2FALt56Aas4X0UcVvF2wXc4xA9jFS9YdA6reADvB6ziMn WaWMU5n%2FBjFQcAKcOBgg%3D%3D"; _cc_id=97ee5b15f4d81a0354cc33708af1b612; _cc_dc=0 Connection: keep-alive
  53. 53. http://bcp.crwdcntrl.net?
  54. 54. Example vulnerable sites Credential misuse cases: – Some dating website • Personal information, relationship • Victim’s dates – Some travel website • Personal information • Itinerary views or even changes
  55. 55. Example vulnerable sites Credential leakage cases: – Impersonation attacks (same as previous) – Unauthorized access to Facebook account • Post comments • Like pages, etc.
  56. 56. Responses from vendors 20 vendors contacted. – Only got 8 responses – Only 2 are manual responses – 1 fixed as of now Through a personal connection, we reached another vendor. – After first fix, vulnerability still exists – Second fix solved all issues
  57. 57. Securing web apps is hard Relying party server Client Third-party server OAuth/SSO Web apps LAMP stack OS Drivers Hardware
  58. 58. Securing web apps is hard Relying party server Client Third-party server Browser extensions/plugins Browser OS Drivers Hardware
  59. 59. Securing web apps is hard Relying party server Client Third-party server Web app LAMP OS Drivers Hardware
  60. 60. SSL Firewall DoS ASLR Kernel space protection DEP Access control
  61. 61. UVa CS security group: secgrp@cs.virginia.edu Yuchen Zhou: yuchen@virginia.edu
  62. 62. Web security (problems) SSL/TLS security – Traffic manipulation Cross-site request forgery (CSRF) – Force unsolicited transactions/POSTs Online social network (OSN) – Fake accounts/comments/likes/tweets/… Social engineering – Varies
  63. 63. Web privacy (problems) Third-party JavaScript – Web identity tracking – Behavioral/Contextual Ad targeting Side channels – Infer user action/information SSL/TLS security (crypto) – Eavesdropping
  64. 64. Logic vulnerabilities Lack of checking/sanitization – Buying stuff for nothing (or even negative price!) Forget to check user against access control list – Get admin rights! Misuse credentials – Authenticating Bob as Alice
  65. 65. Integration type vs vulnerabilities Integration Type Number of sites % of credential misuse % of credential leakage All 1700 12% 8.5% SDK 592 28.9% 3.5% Widget 136 15.4% 2.2% Custom code 972 1.3% 12.3%

×