Yuchen Zhou and David Evans Presented by Simon du Preez Compsci 726 SSOScan: Automated Testing of Web Applications for Single Sign-On Vulnerabilities

 Allows a user to login with a single ID to a number of connected systems  Established internet identity (Twitter, Facebook, Google)  Extra permissions can be issued as needed by the service Single Sign-On (SSO)

Reduces password fatigue Don’t need to remember lots of different passwords Reduces time spent re-entering passwords Lost password claims in IT goes down  Access to more with same credentials  High reliance on authentication system being “up” SSO: Benefits and Drawbacks

How it Works 1. Alice visits a web application and uses SSO 2. Alice is redirected to Identity provider 3. Alice logs into Facebook 4. OAuth credentials issued to application server 5. Application server confirms identity and authenticates the client

 Code  Used to exchange for an access_token  Also requires applications app_secret  Access_token  Represents permissions granted by the user  Issued and forwarded to application at users consent  Signed_request  Used to verify a user’s current login status OAuth Credentials

 Facebook tokens: User Access Tokens, App Access, Tokens, Page Access Token and Client Access Tokens  Facebook User Access Token  Used to read/write Facebook data on their behalf  Obtained via login dialogs  Short-life (~2 hours) and long-life tokens (~60 days)  Tokens are PORTABLE Facebook Access Tokens

 Implementing SSO services can be difficult  Developers make mistakes when integrating SSO APIs  Applications integrating SSO can have vulnerabilities as shown in previous papers Motivation

 Development of SSOScan  Takes a website URL, determines if it uses Facebook SSO and simulates several attacks  Focus is on Facebook  Two parts to SSOScan  Large scale study and investigation of vulnerabilities  Top 20,000 most popular US sites Contribution

 An automatic vulnerability checker for applications using Facebook SSO  Designed for large scale testing  Consists of two main parts: enroller & vulnerability tester  In addition an oracle which determines state SSOScan

 First step: find the login button  Second: login with Facebook SSO  [Third]: Enter remaining details  Website is broken up into elements and analyzed  Rankings to each element  Clicking every element would take up far too much time The Enroller

 Different websites = different registration process  SSOScan must account for registration forms after already signing in  Registration forms filled out  Radio buttons -> tick boxes -> text fields -> submit The Enroller (2)

 Determine if enroller logged a user in  Also used by vulnerability tester to check impersonation attack  Looks for anything indicating account information  Name, , profile  “Welcome Alice” The Oracle

 Control is pass to the vulnerability tester  Five different types of vulnerabilities were looked for The Vulnerability Tester

 Access_tokens are not tied to a specific application Access_token misuse

 Signature of signed request is never checked using app_secret  Attack is similar to access_token misuse except you reuse signed_request as well as access_token Signed_request misuse

 App_secret is given to developer when app is registered  Should always be kept secret  Code and app_secret are used to exchange for an access token. Do this on SERVER SIDE App_secret leak

1. Credentials intentionally put in the URL 2. Credentials present in the content  From this can impersonate users Credential Leaks

Signed_request misuse  Situation described earlier – malicious website  Test application “Mal” developed  Alice's signed_request for Mal obtained  Bob signs into target application using stolen signed_request  Success: Bob = Alice Simulated Attacks

Referer header leak  SSOScan monitors all request data  Compares each referer header to OAuth credentials  A leak is: credentials found in header for a page that contains third-party content Passive Monitoring

 20,000 websites -> 17,913 valid sites  Three days to complete  3.5 minutes per site on average Running SSOScan

 Of the 17,913 sites 1660 had Facebook SSO implementations  The more popular the website, the higher chance the website integrated Facebook SSO  39 / 1660 sites had faulty implementations  Lazy programmers, SEO Purposes, incorrect implementations Results

 202 / 1660 sites misused credentials  126 were misusing both access_token and signed_request  146 /1660 sites leaked Facebook SSO credentials  A total of 345 / 1660 had at least one of the vulnerabilities.  3 websites had both misused and leaked credentials Results (2)

 None of the sites leaked their app_secret  Verified SSOScan was working  Documentation warnings & increased effort Example:  Match.com  Vulnerable to signed_request replacement  Impersonators had access to sensitive information Results (3)

 Two kinds of mistakes identified: Misreporting Facebook SSO  A number of test cases identified  No login button – Only “My Account” button  Interaction with popup window three times. Max click depth = 2  Login button ranked 4 th of all elements Evaluation: Misreporting

 Vulnerabilities were simulated  Confident accuracy of scan is good  A false negative is possible  OAuth string is transformed or encoded  SSOScan checks for exact match Evaluation: Vulnerability Identification

 228 cases which failed registration  47 would never work anyway  Complicated registration process: CAPTCHAs etc.  Oracle Confusion: No ID information  Other: Timeouts, load loading times Automation Failures

 A single click incurs latency  Important to narrow selection  Candidate rank  Visibility Filter  Position  Registration form filter Heuristics Evaluation

 Vulnerable sites contact  Most didn’t care  Facebook contacted  Still didn’t care  Of total 345 vulnerable sites, 48 fixed problems  Two main contributions:  SSOScan Tool  Large scale testing of popular websites Communication and Conclusion

 Front end operations and traffic checked only  Methodology of vulnerability tester unclear  SSOScan only relevant for English websites  Only Facebook SSO implementation checked  Possible tied to Facebook API Criticism

Questions?