Upload
david-evans
View
718
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Guest lecture by Yuchen Zhou http://www.rust-class.org
Citation preview
Catching Pitfalls in Authentication Implementations
Yuchen Zhou(filling in for Prof. David Evans)
Outline
• Authentication, SSL review
• Single Sign-On protocol
• (Part of) My research
University of Virginia cs4414 3
Checks the factors
multiply to produce n
“Trick or Treat?”
“Prove it by factoring n =
2129024631825875754749788201627151749780670396327721627823338321538194 9984056495911366573853021918316783107387995317230889569230873441936471”
”
Problems with this?
3398717423028438554530123627613875835633986495969597423490929302771479
* 6264200187401285096151654948264442219302037178623509019111660653946049
29 October 2013
Authentication (review)
University of Virginia cs4414 5
Checks thatD(x)e mod n =
x
“Trick or Treat?”
Prove it by producing D(x)
for my challenge x
D(x) = xd mod n
29 October 2013
What is the public key? Private key?
I give you x, you give me D(x)
So that D(x)e mod n =
x
University of Virginia cs4414 6
SSL (Secure Sockets Layer)Simplified TLS Handshake Protocol
Client ServerHello
KRCA[Server Identity, KUS]Verify Certificate using KUCA
Check identity matches URL
Generate random K EKUS (K)
Decryptusing KRS
Secure channel using K
29 October 2013
After the handshake, client has KRCA[Server Identity, KUS], what
prevents client from reusing this and impersonating the server?
University of Virginia cs4414 7
SSL (Secure Sockets Layer)Simplified TLS Handshake Protocol
Client ServerHello
KRCA[Server Identity, KUS]Verify Certificate using KUCA
Check identity matches URL
Generate random K EKUS (K)
Decryptusing KRS
Secure channel using K
29 October 2013
The client won’t have KRS, and won’t be able to decrypt for K.
OK, now onto some new stuff…
9
Single Sign-On (SSO) Service
Single Sign-On (SSO) Service
Involves Three parties:• Identity provider
• Relying party
• User
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.
A typical OAuth authentication workflow
Identity Provider(e.g., Facebook)
Relying Party(e.g., espn.com)
Redirect
Visit
OAuth Credentials
Confirm credentials
Authenticated
Login Verify login and issue credentials
User (Web Client)
OAuth Credentials
Permission granting
But this is hard to get right!
SSO SDKsNo worries, IdP SDK came to the rescue!
But this is (still) hard to get right!
Even if the developers follow the guides properly, the application could still be
insecure!
16
The requested response type, one of code or token. Defaults to code…
Facebook documentation example
17
Possible implementation
Facebook back end
dialog/oauth…1
access_token3
access_token2
exchange user info
4
user id/email
5
Welcome, Alice!6
Foo App Client
Foo App Server
response_type = access_token
Access_token
CAADxRthhGccBAFtpBpZAyg80NH6defOZCZAiRPAMCUmxlN3nw5ZBfQIK7YZAtKbCBYszbwZAsjLRbvP3CI2W0U0eXLaQhehZCEOu2LF7RzqxiVCGvTiAZCJ4ZCk5CxILfF2QKfSlsUXJ22y0dtJdA8MQO
Exchange User information
Request: https://graph.facebook.com/me?access_token=CAADxRthhGccBAFtpBpZAyg80NH6defOZCZAiRPAMCUmxlN3nw5ZBfQIK7YZAtKbCBYszbwZAsjLRbvP3CI2W0U0eXLaQhehZCEOu2LF7RzqxiVCGvTiAZCJ4ZCk5CxILfF2QKfSlsUXJ22y0dtJdA8MQO
Response: { "id": "100006071110883", "name": "Syxvq Ldfwpk", "first_name": "Syxvq", "last_name": "Ldfwpk", "link": "https://www.facebook.com/syxvq.ldfwpk", "username": "syxvq.ldfwpk“….}
User’s FB ID
20
Possible implementation
Facebook back end
dialog/oauth…1
access_token3
access_token2
exchange user info
4
user id/email
5
Welcome, Alice!6
Foo App Client
MaliciousApp Client
Foo App Server
Possible Attack
access_token3
access_token4
Welcome Alice?!7
exchange user info
5
user id/email
6
response_type = access_token
Key to this pitfall:
Developers don’t understand the difference between authentication
and authorization.
In OAuth protocol, access_token can only be used to authorize, but not
authenticate!
Signed_request to the rescue!
c47YUduADVDyJs4yV6Lvq2V0yxPxSX_rJb-zzhICFRQ.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUIwRGpVaW1TREpRcFdTY3M0Yk1rX2tZNU41SFBhZTZqVmNEdVdpM2ktc1VJaHN4RmtHR2tneEU3UFFVYVBtbXdUV2dzQWg5QUI1RmFzeXVOZkt3NGpGMDE3ZGY2WEEyazB6M3Q2azNYYjFDVGJXQzZJZEtoaDdsRnp4TTExZm8tWGdYblZXbUxibU1fMmJHWDhFVWlxQk1ybVpweUxTUzI0TUw0ZnB6WmhRZjU5SzU4bkY4LS1yT3M3QVI4RG0xb0xaeDduQkRiQVl4bmVqcnhOc0xLZTB2UFhBb2JXaTVHNkxfOU1JS192alg2anZUSzlCcDItbEMyemdveFNFb01BU2g0NzFqUnMwd2JzT29HUW1ZVDVndGRFaWcxNzZMYkt1Q1ZqMDd1a2ZFejlEdU1wX09xSDFIVWFPWlRVNjlwNFZnbVh0Ql9NVzQ3YWlmRGJHSTRYVyIsImlzc3VlZF9hdCI6MTM3OTQyNDgxNCwidXNlcl9pZCI6IjEwMDAwMzkyOTkwNjEzNyJ9 Base64 Encoded, signed by
application’s secret key
Signature
Signed_request to the rescue!
{"algorithm":"HMAC-SHA256","code":"AQB0DjUimSDJQpWScs4bMk_kY5N5HPae6jVcDuWi3i-sUIhsxFkGGkgxE7PQUaPmmwTWgsAh9AB5FasyuNfKw4jF017df6XA2k0z3t6k3Xb1CTbWC6IdKhh7lFzxM11fo-XgXnVWmLbmM_2bGX8EUiqBMrmZpyLSS24ML4fpzZhQf59K58nF8--rOs7AR8Dm1oLZx7nBDbAYxnejrxNsLKe0vPXAobWi5G6L_9MIK_vjX6jvTK9Bp2-lC2zgoxSEoMASh471jRs0wbsOoGQmYT5gtdEig176LbKuCVj07ukfEz9DuMp_OqH1HUaOZTU69p4VgmXtB_MW47aifDbGI4XW","issued_at":1379424814,"user_id":"100003929906137"}
Base64 Decoded
User’s FB ID
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.
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!
There could be many more like these…
Goal:Systematically find such pitfalls
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.
Modeling: Analogy
Proving the entire car never blows up is hard!
Modeling: Analogy
Proving the entire engine never blows up is hard!
Modeling Analogy
Proving a single fuel injector never blows up is probably easier!
ModelingAdvantages
• Turn complicated system into simpler systems that are amenable to analysis.
• Abstract away irrelevant details.
• Reason modules separately, combine smaller proofs to bigger ones.
Disadvantages
• Model behavior does not necessarily agrees with original system.
• Details abstracted away may come back and ‘haunt’ the model.
• Complicated interactions between modules might be missed.
33
Modeling SSO System
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
MalApp
C
Mallory
Abstract module subject to dev guideConcrete module with src or documentationBlack-box concrete module Abstract module subject to knowledge pool
34
SDK models
Facebook PHP Source code Boogie PL Model
35
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;}
API models
Facebook Dialog API documentation Boogie model
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;}
36
Results overviewExplicated three SDKs: (6 months)
Many implicit assumptions were found:
5 cases reported, 4 fixed, 3 bounties (3x).
One case reported;documentation revised.
Paragraph added to OAuth 2.0 standard.
Facebook SSO PHP SDK
Windows 8 SDK for modern apps
Windows Live connect SDK
Automatic scanning applications for these vulnerabilities
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.
• access_token misuse• signed_request misuseMisuse
• client_secret appears at client side• OAuth credentials leak via referrer
header• OAuth credentials leak via DOM content
Credentialleakage
Approach
Web server source/binary not visible from client side.
Simulated attacks with traffic and application state monitoring
41
App driver
42
App driver
43
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.
DEMO time
• Ssoscan.org
• Pick your favorite site, check if it’s secure.
45
Evaluation: Dataset
Top US 20K sites (Quantcast.com) excluding DNS errors, 4xx/5xx response code.
google.comyoutube.comfacebook.commsn.comamazon.comtwitter.comebay.compinterest.comyahoo.combing.commicrosoft.com…
Results overview17 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
Not Vulnerable77.4%
Buggy 2.3%
Valid Top ranked sites (17913)
No Facebook SSO, 82.9 %
Timeout/error 7.6%
Facebook SSO, 9.5%
Vulnerable20.3%
1700 Sites using Facebook SSO
Facebook SSO support vs. site ranking
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
% s
uppo
rting
FB
SSO
Site rank percentile (20K)1 10 20 30 40 50 60 70 80 90 100
Misuse vulnerability vs. site ranking
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
% v
ulne
rabl
e
Site rank percentile (20K)1 10 20 30 40 50 60 70 80 90 100
Trends
More popular sites tend to include Facebook SSO more.
However, big and popular websites are just as vulnerable as lower-profiled sites.
Credential leakage vs. Site Ranking
Site rank percentile (20K)
1 10 20 30 40 50 60 70 80 90 100
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
% v
ulne
rabl
e
Credential leakage explained
OAuth credentials appears in the URL bar
http://www.dailymail.co.uk/registration/social/register.html?param__host=www.dailymail.co.uk¶m_code=AQCajy7bQs32zCXgMlcfNMeFA0Y-hRPN06guZI8doD9AfQJn7IDNUTniVnPiSf7cFVUFs4u_lKpHCmXi4XQStbLuPN1ur8ynzVY8zqENn3NK3UEK1S0AXeExzlRfUVCbilOler5YImj2HGak86kGzZcfuby3ATyJsEQTdc1fXmnw_nruVXj-jSiNiEKYuyOXQNfAYGDezZZkQe_81agmv7FxcgS9mUspWrnnHLi1nP_9ZpyBU5dUeMTsPV9qXbp3Vs2_3CcMVzd7Sma0s8A1xR-IH-D_Y9E96mdT_LKKU8lV_T-ZrphLCwYmj9PXXGZ9wrI#_=_
HTTP response body
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¶m_code=AQCajy7bQs32zCXgMlcfNMeFA0Y-hRPN06guZI8doD9AfQJn7IDNUTniVnPiSf7cFVUFs4u_lKpHCmXi4XQStbLuPN1ur8ynzVY8zqENn3NK3UEK1S0AXeExzlRfUVCbilOler5YImj2HGak86kGzZcfuby3ATyJsEQTdc1fXmnw_nruVXj-jSiNiEKYuyOXQNfAYGDezZZkQe_81agmv7FxcgS9mUspWrnnHLi1nP_9ZpyBU5dUeMTsPV9qXbp3Vs2_3CcMVzd7Sma0s8A1xR-IH-D_Y9E96mdT_LKKU8lV_T-ZrphLCwYmj9PXXGZ9wrI
• Cookie: _cc_aud="ABR4nCXRzyvDcRzH8fdKO0g7iBbWLhoOXFwpTXEZseVHDqKZmdayi2R%2B9N2UclD7Sn5FODj5C%2FwLWhzERRzMyUp%2BXBzxfH0vj96f9%2Bf9fn8%2Bn6%2BZWWw%2B6zXzhCtPR1GLmPnrHHPMEiXHgmZLvUSpU9g8F2dCiz23EP2G6RcYv4BkGEY9kP%2BiZ66LaHEXqg9gvcr%2Bv8w92DY7h7zktvJEmRJRn5r5JmCtAs0BqLmGwA%2BM6RDplHY2wOCkChLMWY0Qxa6gvo1BLWVyI41Qe0cucyL2oNipggc9Tzt1Sb3LyqPmvcGCDzqU8w%2FoSJ8UTLmK3mHjGWay5NJlIndfaKyrN3N3oKAuhQ%2BIH7MY0u8I3UCwCWYvIafjtg5DvKg7HEJ%2FNyzrYnOvf%2FwCWZyKIA%3D%3D"; _cc_cc="ACN4nGNQsDRPTTVNMjRNM0mxMEw0MDY1SU42NjY3sEhMM0wyMzRiAIKgzAK2P1t7qxgYGB1f350VCBJjYNt2bQ8jA8spBob%2FjIwMjEC57se1aALXrdAEHn1FE7jlhSrg%2F%2BUxkHG%2FASQAYjA2AIUFuBN2McFEYcpBstwJO7GKb21pQBi7tWczgrNcThxojSREx7L7uxEcZa63WM3iqm%2FALt56Aas4X0UcVvF2wXc4xA9jFS9YdA6reADvB6ziMnWaWMU5n%2FBjFQcAKcOBgg%3D%3D"; _cc_id=97ee5b15f4d81a0354cc33708af1b612; _cc_dc=0
• Connection: keep-alive
http://bcp.crwdcntrl.net?
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
Example vulnerable sites
Credential leakage cases:– Impersonation attacks (same as previous)– Unauthorized access to Facebook account• Post comments• Like pages, etc.
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
Securing web apps is hard
OAuth/SSO
Web apps
LAMP stack
OS
Drivers
Hardware
Relying party serverClient
Third-party server
Securing web apps is hard
Browser extensions/plugins
Browser
OS
Drivers
Hardware
Relying party serverClient
Third-party server
Securing web apps is hard
Web app
LAMP
OS
Drivers
Hardware
Relying party serverClient
Third-party server
OS Security is important!
ASLR
DEPAccess control
Kernel space protection
Firewall
DoS
SSL
UVa CS security group: [email protected]
Yuchen Zhou: [email protected]
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
Web privacy (problems)
Third-party JavaScript– Web identity tracking– Behavioral/Contextual Ad targeting
Side channels– Infer user action/information
SSL/TLS security (crypto)– Eavesdropping
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
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%