iTrustPage: Pretty Good Phishing Protection

1. iTrustPage: Pretty Good Phishing Protection Stefan Saroiu, Troy Ronda, and Alec Wolman University of Toronto and Microsoft Research

2. Phishing Attacks Cost Real Money! Hundreds of millions of $$$ cost to U.S. economy Affects 1+ million Internet users in U.S. alone Real cost: Erosion of trust in Web as e-commerce platform 40% of people not banking online do not trust Web!!!

3. Myriad of Solutions Proposed • Spam filters [CMU ‘06, SpamAssassin, Outlook] • Browser blacklists [IE7, FF 2.0, Opera] • Password managers [Princeton ‘05, Stanford ‘06, Berkeley ‘06] • Out-of-band authentication [CMU ‘06, Stanford ‘06] • User-created labels, warnings [Stanford ‘06] • Automatic fillers [MIT ‘06] • Centralized approaches [MSR ‘06]

4. Yet… the Problem is Growing! • Number of phishing sites grew 10X in 18 months • 2004 -- mid 2006 • Banks claim phishing becoming #1 source of fraud • Phishing e-mails becoming personalized • sophisticated and hard-to-filter • Must look into new anti-phishing approaches!

5. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

6. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

7. Current Approaches’ Shortcomings • Spam filters + blacklists imperfect and too slow • Phishing sites’ average uptime is 4.5 days • Password managers have usability problems • Based on hard-to-grasp concepts, uncommon tasks • Personalized visual clues • Rely on users to be diligent • Automatic password fillers • Easy to fool + they create local password repository

8. Lessons Learned • Anti-phishing tools must be intuitive + easy-to-use • Users must perform very simple, common tasks • Relying on users to be diligent unlikely to work • Phishing is becoming personalized • Can’t rely on static filters • Anti-phishing tools must re-act quickly to attacks • Cannot wait for updates or new filters

9. Our Approach: iTrustPage • Prevents users from filling out phishing forms • Does not rely on static filters • Users perform simple, common, and intuitive tasks • Doesn’t rely on users to stay vigilent • Harder-to-fool • Stops users whenever key is pressed on any site whether a form is present or not

10. High-Level View of Our Tool • If user fills suspicious form, user asked for input: • Describe search terms for questionable form • i.e., Is the user visiting an well-established site? • If yes, site is unlikely to phish • Visual comparison of questionable Web form with Web forms arrived at via Google result • i.e., Do these two forms look visually the same? • If yes, site is likely to phish

11. Live Demonstration – Trusted Page • Navigate to Google and perform a search

12. Live Demonstration – Untrusted Page

13. Live Demonstration – Phishing Page

14. Our Two Key Observations • Rely on user input to help disambiguate between legit and fake sites • Certain decision making tasks are hard to automate reliably, yet very easy for people to decide • e.g., deciding when 2 Web sites appear visually similar • Use external Web information repositories • Use Internet sources to help determine legitimacy of particular Web site or form • e.g., many attacks target well-known, popular Web sites + search engines can identify such sites

15. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

16. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

17. Automatic Classification • iTrustPage stores locally previously visited forms • No need to re-validate form • Two additional conservative heuristics • Google’s PageRank >= 5 • Must be verified by TrustWatch • Heuristics could be exploited by attackers • Fundamental trade-off between usability & security

18. Validation • Web form is validated if: • Our conservative heuristics validate it (automatically) • Form’s domain in top 10 domains from Google • Based on user-input keywords • Repeat step 2 k-times, refining search keywords • Where k is variable depending on form’s PageRank • Higher PageRank means lower k • When everything else fails, raise flashy warning box • Fundamental corner-case, common to all tools

19. Implementation • 5,200 lines of code for Firefox extension • Tested with Linux, Mac, Windows • Open-source, freely available • 900 downloads in one month • Recently released ver. 2.0 with better interface • It still needs lots of work though

20. Circumventing iTrustPage • Create phishing page on site with high PageRank • Break into popular site • “Google bomb” attack • Compromise user’s Web browser • In this case, all bets are off (spyware!)

21. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

22. Outline Motivating the need for new approaches Lessons learned from current approaches iTrustPage demo Design and implementation Evaluation Conclusions

23. Evaluation Strategy • Performance evaluation • Evaluating iTrustPage’s effectiveness • Usability study

24. Evaluation Strategy • Performance evaluation • Evaluating iTrustPage’s effectiveness • Usability study

25. Methodology • Would users notice a performance degradation? • iTrustPage prefetches PageRank and TrustWatch • Load pages of randomly chosen 115 US banks • Average PC: P III, 256MB RAM, U of T network • Compare page loading times of unmodified browser to browser+iTrustPage

26. Very Little Additional Overhead Average site has 27ms extra overhead

27. Evaluation Strategy • Performance evaluation • Evaluating iTrustPage’s effectiveness • Usability study

28. Questions • Are automatic validation heuristics correct? • How often do users need to validate forms? • For hard-to-validate forms, how often do users need to revise search terms?

29. Questions • Are automatic validation heuristics correct? • How often do users need to validate forms? • For hard-to-validate forms, how often do users need to revise search terms?

30. Methodology • Can’t measure from iTrustPage’s deployment • We do not record number of forms visited by users • Use previously collected traces of Websites • Research log: 14 research lab users over 3.5 months • IRCache log: 8,714 users over 6.5 months • Assume all pages have forms

31. 40% Sites are Automatically Validated

32. Users are Disrupted Less over Time This data is from iTrustPage’s deployment

33. Evaluation Strategy • Performance evaluation • Evaluating iTrustPage’s effectiveness • Usability study

34. Methodology • 4-step study: • Fill-out preliminary survey to gather background info • Present tutorial on iTrustPage • Ask users to perform six steps, including: • Visit popular legit form • Visit unpopular legit form, could be easily found on Google • Visit phishing site • Visit unpopular legit form, can’t be found on Google • Post-study questionnaire • 15 participants

35. More disruptions, less easy to use!

36. Security vs. Usability

37. Security vs. Usability

38. Conclusions • New anti-phishing tool based on two insights • User input can be used to distinguish legit from fake sites, as long as interaction is simple and intuitive • Internet information repositories can be used to assist user with their decision • Our evaluation has shown: • Negligible performance overhead • Automatic classification heuristics correct and useful • Tool becomes less disruptive over time • User like tool when few disruptions only

39. Works Surprisingly Well Download iTrustPage (Firefox Extension) www.cs.toronto.edu/~ronda/itrustpage/