Catching Pitfalls in Authentication Implementations (Yuchen Zhou)

transcript

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)

Checks thatD(x)e mod n =

“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 =

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?

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…

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

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!

The requested response type, one of code or token. Defaults to code…

Facebook documentation example

Possible implementation

Facebook back end

dialog/oauth…1

access_token3

access_token2

exchange user info

user id/email

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

Possible implementation

Facebook back end

dialog/oauth…1

access_token3

access_token2

exchange user info

user id/email

Welcome, Alice!6

Foo App Client

MaliciousApp Client

Foo App Server

Possible Attack

access_token3

access_token4

Welcome Alice?!7

exchange user info

user id/email

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.

Modeling SSO System

FooAppC

Client SDK

Client runtime

Identity Provider (IdP)

FooAppS

Service SDK

Service runtime

MalApp

Mallory

Abstract module subject to dev guideConcrete module with src or documentationBlack-box concrete module Abstract module subject to knowledge pool

SDK models

Facebook PHP Source code Boogie PL 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;}

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;}

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

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

App driver

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.

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

Site rank percentile (20K)1 10 20 30 40 50 60 70 80 90 100

Misuse vulnerability vs. site ranking

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

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&param_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&param_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

Drivers

Hardware

Relying party serverClient

Third-party server

Browser extensions/plugins

Browser

Drivers

Hardware

Third-party server

Web app

Drivers

Hardware

Third-party server

OS Security is important!

DEPAccess control

Kernel space protection

Firewall

UVa CS security group: secgrp@cs.virginia.edu

Yuchen Zhou: yuchen@virginia.edu

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%

Catching Pitfalls in Authentication Implementations (Yuchen Zhou)

Technology