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 Defending against Phishing without Client-side Code Amir Herzberg Bar-Ilan University 6 Sep 2008

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

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:

OWASP Goal: Server-based Defense from Phishing  Phishing: stealing user’s credentials (password)  Typical phishing vectors:  Spoofed (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  Detect, block phishing site  Prevent expose of password to spoofed site  Without new/extended browser  But doesn’t SSL already do this?? 4

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?

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 s, sites (google?)  Isn’t this good enough?  Can/should we do more ?  Without changing the browser?

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

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

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

OWASP SubmitWeb: Realistic Phishing Experiment [Dvorkin+H]  Real-use assignment submission system  Repetitive web and 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

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)

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

OWASP SubmitWeb: Detection Rates 13

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

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

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

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. :  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

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

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

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 s  Provide toolkit, help for sites 20