1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Defending against Phishing without Client-side Code Amir Herzberg Bar-Ilan University herzbea@macs.biu.ac.il 6 Sep 2008

2. OWASP Server-based Defense from Phishing: Agenda  Phishing attacks and defenses  Esp. SSL login pages  Secure-usability testing of phishing defenses: SubmitWeb  Login Bookmarks 2

3. OWASP 3 Sources This presentation is based on:  TrustBar and related secure-usability experiments, with Ahmad Jbara (BIU)  SubmitWeb: real-use phishing experiments, Joint work with Alex Dvorkin (BIU)  BeamAuth by Ben Adida, see: http://ben.adida.net http://ben.adida.net

4. OWASP Goal: Server-based Defense from Phishing  Phishing: stealing user’s credentials (password)  Typical phishing vectors:  Spoofed email (usually with link to spoofed site)  From attacker-controlled site  Single-Sign On (or `click to login into your…`)  Or, XSS or MITM/Pharming attacks (on victim site/`google`)  How to prevent?  Detect, block phishing email  Detect, block phishing site  Prevent expose of password to spoofed site  Without new/extended browser  But doesn’t SSL already do this?? 4

5. OWASP (c) Amir Herzberg 5 (In)Secure Login using SSL  Example: login form in Chase’s site  Chase must know what they do, right?  Wrong:  Chase’s site or Phisher’s site?  SSL or misleading padlock?  Fact: page loaded w/o SSL  SSL invoked only on `submit’  Spoofed page submits to Phisher…  Most login sites are better:  Invoke SSL, no misleading padlock  Secure?

6. OWASP (c) Amir Herzberg 6 Typical Login Sites are Better…  Typical, `good’ login site:  Invoke SSL (to authenticate page, encrypt PW)  No misleading padlock  User education:  Look for URL, padlock, https  Never follow links in emails, sites (google?)  Isn’t this good enough?  Can/should we do more ?  Without changing the browser?

7. OWASP Phishing Attacks on Typical (`good’) Sites  Wrong URL attacks  Homographic: submitweb.com vs. submitvveb.com  Misleading: submitweb.c6.com vs. c6.submitweb.com  Pharming/DNS Poisoning/MITM attacks  MITM sometimes easy, e.g. via WiFi  DNS often vulnerable  But what of SSL? Three options: 1.No SSL – will user notice?? 2.SSL, using wrong URL 3.SSL… with Phisher’s CA  Browser will ask user… will user approve? Notice? 7

8. OWASP Server-based Defense from Phishing: Agenda  Phishing attacks and defenses  Esp. SSL login pages  Secure-usability testing of phishing defenses: SubmitWeb  Login Bookmarks 8

9. OWASP Do Users Notice ?  Need experiments with users… what a pain!  [H+Jbara] `Classical’ browser vs. Improved  Improved (TrustBar): displays name/logo for site  Detection rate: 67%  96%  Other improvements:  False positives: 19%  3%  Decision time: 15sec  9sec  But in reality:  Almost no false positives  Decision time < 1sec   Need more realistic experiment! 9

10. OWASP SubmitWeb: Realistic Phishing Experiment [Dvorkin+H]  Real-use assignment submission system  Repetitive web and email activities  Very few `attacks’ over long period of use  Significant student population  Early (2008) results: 492 BIU CS students  Each randomly assigned one defense type  Randomly (very rarely) attacked 10

11. OWASP SubmitWeb: Simulated Attacks 11 Homograph Attack (redirection to non-SSL page). Homograph Attack (redirection to SSL page). Corrupted Certificate. Non-SSL (e.g. MITM)

12. OWASP SubmitWeb: Evaluated Defense Mechanisms 12  Passive indicators  None (`classical’ browser indicator only)  Display name of site (from certificate)  Display user-selected name for site  Interactive indicators  Interactive site user-selected name  Interactive site user-selected image  Login bookmark  User must click on bookmark to login  Details later

13. OWASP SubmitWeb: Detection Rates 13

14. OWASP Server-based Defense from Phishing: Agenda  Phishing attacks and defenses  Esp. SSL login pages  Secure-usability testing of phishing defenses: SubmitWeb  Login Bookmarks 14

15. OWASP What about login bookmarks? 15  How login bookmarks work?  Server generates special bookmark per user  User `drags’ bookmark into browser  To login, user must click on bookmark  Bookmark contains key for 1 st authentication  Server displays user-selected image  User (confirms image and) enters password  2 nd authentication: password over SSL  Wrong-URL, no-SSL attacks irrelevant  Testing focused on response to email

16. OWASP Login Bookmark: Results 16  Login bookmark mechanism increases user security against phishing attacks  Bookmark reduced following links, success:

17. OWASP Login Bookmark: Details  1 st idea: JavaScript (with `key’) in bookmark  Problem: current page can change JavaScript, hence access `key`  Better idea: use URL Fragment Identifier, e.g. : http://site.com/page#paragraph http://site.com/page#paragraph  used to designate portion of page  browser scrolls to the appropriate location – if exists  never sent to server but accessible from JavaScript  Changing fragments does not cause page reload 17

18. OWASP Login with Bookmark + Interactive Image  Initialization:  Select image  Install bookmark (with ID,Key in fragment)  Login process:  User clicks on https (SSL) bookmark, page loaded  Script reads ID, Key, authenticates to server  Server sends secret image (over SSL)  Script displays image  User must click image, then script asks for password  User enters password  Script sends password (over SSL) 18

19. OWASP Resistance to Specific Attacks  Spoofed site and prompt, user enters PW  Password exposed, ID secret  Note: user ignored no/wrong image!  Replace bookmark  Password exposed, ID still secret  Expose bookmark (access to PC, tricking user)  ID exposed, password OK  Fails  against:  Corrupted server site (XSS sending rogue script)  Rogue CA (approved by user), spoofed site  Rogue browser 19

20. OWASP Future Plans  Continue, extend SubmitWeb experiments  More data, more confidence  Compare browsers  Compare variants of bookmark defense  E.g. server sends few images  may prevent `dictionary attack’ even from user with access to bookmark  Measure usability  Measure with anti-phishing filtering  Ability to identify clone emails  Provide toolkit, help for sites 20