Towards Eradicating Phishing Attacks

1. Towards Eradicating Phishing Attacks Stefan Saroiu University of Toronto

2. Today’s anti-phishing tools have done little to stop the proliferation of phishing

3. Many Anti-Phishing Tools Exist

4. Phishing is Gaining Momentum

5. Current Anti-Phishing Tools Are Not Effective • Let’s look at new approaches & new insights! • Part 1: new approach: user-assistance • Part 2: need new measurement system

6. Part 1 iTrustPage: A User-Assisted Anti-Phishing Tool

7. The Problems with Automation • Many anti-phishing tools use auto. detection • Automatic detection makes tools user-friendly • But it is subject to false negatives • Each false negative puts a user at risk

8. What are False Negatives & False Positives? • Example of a false negative: • Phishing e-mail not detected by filter heuristics • Example of a false positive: • Legitimate e-mail dropped by filter heuristics

9. Current Anti-Phishing Tools Are Not Effective • Most anti-phishing tools use auto. detection • Automatic detection makes tools user-friendly • But it is subject to false negatives • Each false negative puts a user at risk

10. Can false negatives be eliminated?

11. Case Study: SpamAssassin • SpamAssassin: one way to stop phishing • Methodology • Two e-mail corpora: • Phishing: 1,423 e-mails (Nov. 05 -- Aug. 06) • Legitimate: 478 e-mails from our Sent Mail folders • SpamAssassin version 3.1.8 • Various levels of aggressiveness

12. False Negatives Can’t Be Eliminated

13. Trade-off btw. False Negatives and False Positives Reducing false negatives increases false positives

14. Summary: Automatic Detection • False negatives put users at risk • Hard to eliminate false negatives • Making automatic detection more aggressive increases rate of false positives • Appears to be fundamental trade-off • Let’s look at new approaches

15. New Approach: User-Assistance • Involve user in the decision making process • Benefits: • False-positives unlikely and more tolerable • Combine with conservative automatic detection • Use detection that is hard-for-computers but easy-for-people

16. Outline • Motivation • Design of iTrustPage • Evaluation of iTrustPage • Summary of Part 1

17. Two Observations about Phishing 1. Users intend to visit a legitimate page, but they are misdirected to an illegitimate page 2. If two pages look the same, one is likely phishing the other [Florêncio & Herley - HotSec ‘06]

18. Two Observations about Phishing 1. Users intend to visit a legitimate page, but they are misdirected to an illegitimate page 2. If two pages look the same, one is likely phishing the other [Florêncio & Herley - HotSec ‘06] Idea: use these observations to detect phishing

19. Involving Users • Determine “intent” • Ask user to describe page as if entering search terms • Determine whether pages “look alike” • Ask user to detect visual similarity between two pages • Tasks are hard-for-computers but easy-for-people

20. iTrustPage’s Validation • When user enters input on a Web page • Two-step validation process • Conservative automatic validation • Simple whitelist -- top 500 most popular Web sites • Cache -- avoid “re-validation” • Flag page “suspicious”; rely on user-assistance

21. iTrustPage: Validating Site

22. Step 1: Filling Out a Form

23. Step 2: Page Validated

24. iTrustPage: Avoid Phishing Site

25. Step 1: Filling Out a Suspicious Page

26. Step 2: Visual Comparison

27. Step 3: Attack Averted

28. Two Issues: Revise & Bypass • What if users can’t find the page on Google? • Visiting an un-indexed page • Wrong/ambiguous keywords for search • iTrustPage supports two options: • Revise search terms • Bypass validation process • Similar to false negatives in automatic tools

29. Outline • Motivation • Design of iTrustPage • Evaluation of iTrustPage • Summary of Part 1

30. Methodology • Instrumented code sends anonymized logs: • Info about iTrustPage usage • High-Level Stats: • June 27th 2007 -- August 9th, 2007 • 5,184 unique installations • 2,050 users with 2+ weeks of activity

31. Evaluation Questions • How disruptive is iTrustPage? • Are users willing to help iTrustPage’s validation? • Did iTrustPage prevent any phishing attacks? • How many searches until validate? • How effective are the whitelist and cache? • How often do users visit pages accepting input?

32. How disruptive is iTrustPage?

33. iTrustPage is not disruptive Users interrupted on less than 2% of pages After first day of use, 50+% of users never interrupted

34. Are users willing to help iTrustPage’s validation?

35. Many Users are Willing to Participate Half the users willing to assist the tool in validation

36. Did iTrustPage prevent any phishing attacks?

37. An Upper Bound • Anonymization of logs prevents us from measuring iTrustPage’s effectiveness • 291 visually similar pages chosen instead • 1/3 occurred after two weeks of use

38. Summary of Evaluation • Not disruptive; disruption rate decreasing over time • Half the users are willing to participate in validation • Pages with input are very common on Internet • iTrustPage is easy to use

39. Summary of Part 1 • An alternative approach to automation: • Have user assist tool to provide better protection • Our evaluation has shown our tool’s benefits while avoiding pitfalls of automated tools • iTrustPage protects users who always participate in page validation

40. What is the Take-Away Point?

41. What is the Take-Away Point? usability security User-Assistance Automatic Detection

42. What is the Take-Away Point? Many of today’s tools usability security User-Assistance Automatic Detection

43. What is the Take-Away Point? Many of today’s tools iTrustPage usability security User-Assistance Automatic Detection

44. Part 2Bunker: A System for Gathering Anonymized Traces

45. Motivation • Two ways to anonymize network traces: • Offline: anonymize trace after raw data is collected • Online: anonymize while it is collected

46. Motivation • Two ways to anonymize network traces: • Offline: anonymize trace after raw data is collected • Online: anonymize while it is collected • Today’s traces require deep packet inspection • Privacy risks make offline anonymization unsuitable

47. Motivation • Two ways to anonymize network traces: • Offline: anonymize trace after raw data is collected • Online: anonymize while it is collected • Today’s traces require deep packet inspection • Privacy risks make offline anonymization unsuitable • Phishing involves sophisticated analysis • Performance needs makes online anon. unsuitable

48. Simple Tasks are Very Slow • Regular expression for phishing:" ((password)|(<form)|(<input)|(PIN)|(username)|(<script)|(user id)|(sign in)|(log in)|(login)|(signin)|(log on)|(signon)|(signon)|(passcode)|(logon)|(account)|(activate)|(verify)|(payment)|(personal)|(address)|(card)|(credit)|(error)|(terminated)|(suspend))[^A-Za-z]” • libpcre: 5.5 s for 30 M = 44 Mbps max

49. Motivation • Two ways to anonymize network traces: • Offline: anonymize trace after raw data is collected • Online: anonymize while it is collected • Today’s traces require deep packet inspection • Privacy risks make offline anonymization unsuitable • Phishing involves sophisticated analysis • Performance needs makes online anon. unsuitable

50. Motivation • Two ways to anonymize network traces: • Offline: anonymize trace after raw data is collected • Online: anonymize while it is collected • Today’s traces require deep packet inspection • Privacy risks make offline anonymization unsuitable • Phishing involves sophisticated analysis • Performance needs makes online anon. unsuitable • Need new tool to combine best of both worlds