Context-Aware Phishing Attacks and Client-Side Defenses

1. Context-Aware Phishing Attacks and Client-Side Defenses Collin Jackson Stanford University

2. Context-aware Phishing C. Jackson, A. Bortz, D. Boneh, J. Mitchell (WWW ’06) • Bank of America customers see: • Wells Fargo customers see: • Works in all major browsers • Design issue, not a just bug

3. Example Attacks • Query visited links: <style>a#visited { background: url(track.php?example.com); }</style><a href="http://example.com/">Hi</a> • Time browser cache: <script>start = new Date();</script> <img src="http://example.com/logo.gif" onload="end = new Date(); if (end.getTime() – start.getTime() < 5) { // image was in cache }"> • Block cache timing, background image?

4. Chameleon Pages • No JavaScript required • No server involvement • Even works in Outlook 2002

5. Perspectives • Phisher: Where do you bank? • China: Have you been to subversive sites? • Amazon: Can I show contexual ads? • Phished site: Can I check history against phishing blacklist? • PayPal: Can I use history as 2nd factor? • Sensitive website: Can I protect visitors? • Browser vendor: Can I protect users at every site?

6. SafeCache • Browser extension for Firefox • Intercept requests to browser cache • If no referrer, allow request • If URL has referrer: • Store referrer host with cache entry • Cache hit only on referrer host match

7. SafeHistory • Intercept requests to browser history database • For each history entry, record referrers • Color visited link if: • It’s a same-site link, or • Cross-site link was visited from this site

8. Server-Side Countermeasures M. Jakobsson, S. Stamm (WWW ’06) • Hide internal links with session ID that is hard for the attacker to guess • http://www.bank.com/?sessionid=AB52F5104ED • Obfuscate external inbound links by polluting the history with pages from other sites • bankofamerica.com, wellsfargo.com, chase.com • Still leaks some information • Separate content for automated robots

9. pwdA = pwdB vulnerable site Common Password Problem Bank A high security site pwdA Site B • Phishing attack or break-in at site B reveals pwd at A • Server-side solutions will not keep pwd safe • Solution: Strengthen with client-side support

10. pwdA = pwdB PwdHash B. Ross, C. Jackson, N. Miyake, D. Boneh, J. C. Mitchell (USENIX Sec ’05) • Generate a unique password per site • HMACfido:123(banka.com)  Q7a+0ekEXb • HMACfido:123(siteb.com)  OzX2+ICiqc • Hashed password is not usable at target site hash(pwdA, BankA) Bank A hash(pwdB, SiteB) Site B

11. User Interface Spoofing • Attacker can display fake password fields or dialogs: • Password recorded using JavaScript • Sent to attacker in the clear

12. Trusted Password Interfaces • Password prefix • PwdHash • Secure attention sequence • Isolated screen area • Trusted image or phrase • Passmark • SpyBlock Starts with @@

13. Keylogger Spyware Problem • Attacker observes login on local machine • Password is sent to attacker for later use • Screenshot can observe “screen keyboards” pwdA Bank A pwdA pwdA Attacker

14. Transaction Generator Problem • Why bother with passwords? • Once user is logged in, attacker can: • Corrupt user requests • Issue unauthorized requests Bank A authenticated channel $$$ Attacker

15. SpyBlock C. Jackson, D. Boneh, J. C. Mitchell • Isolated component for authentication • Untrusted environment for user apps

16. Authentication modes • Hashing, injection require no server assistance • Server support for additional protection

17. Password injection • Intercept outbound requests and insert password • Check for password fields in HTML to deter reflection

18. Transaction confirmation • Application environment cannot MAC fake transaction • Unique transaction ID prevents replay attacks

19. Project websites • Phishing • Phishing + common pwd • Phishing + common pwd + spyware safehistory.com safecache.com spoofguard.org pwdhash.com getspyblock.com