Context-Aware Phishing Attacks and Client-Side Defenses

Collin JacksonStanford University

Context-aware Phishing

• Bank of America customers see:

• Wells Fargo customers see:

• Works in all major browsers• Design issue, not a just bug

C. Jackson, A. Bortz, D. Boneh, J. Mitchell (WWW ’06)

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?

Chameleon Pages

• No JavaScript required

• No server involvement

• Even works in Outlook 2002

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?

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

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

Server-Side Countermeasures

• 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

M. Jakobsson, S. Stamm (WWW ’06)

Common Password Problem

Bank A

vulnerable site

high security site

pwdA

pwdB

= pwdA

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

Site B

PwdHash

Bank A

hash(pwdB, SiteB)

hash(pwdA, BankA)

Site B

• 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

pwdA

pwdB

=

B. Ross, C. Jackson, N. Miyake, D. Boneh, J. C. Mitchell (USENIX Sec ’05)

User Interface Spoofing

• Attacker can display fake password fields or dialogs:

• Password recorded using JavaScript

• Sent to attacker in the clear

Trusted Password Interfaces

• Password prefix– PwdHash

• Secure attention sequence

• Isolated screen area• Trusted image or

phrase– Passmark– SpyBlock

Starts with @@

Keylogger Spyware Problem

• Attacker observes login on local machine• Password is sent to attacker for later use• Screenshot can observe “screen keyboards”

Bank A

pwdA

Attacker

pwdA

pwdA

Transaction Generator Problem

• Why bother with passwords?• Once user is logged in, attacker can:

– Corrupt user requests– Issue unauthorized requests

Bank A

$$$

Attacker

authenticated channel

SpyBlock

• Isolated component for authentication• Untrusted environment for user apps

C. Jackson, D. Boneh, J. C. Mitchell

Authentication modes

• Hashing, injection require no server assistance

• Server support for additional protection

Password injection

• Intercept outbound requests and insert password• Check for password fields in HTML to deter reflection

Transaction confirmation

• Application environment cannot MAC fake transaction• Unique transaction ID prevents replay attacks

Project websites

• Phishing

• Phishing + common pwd

• Phishing + common pwd + spyware

safehistory.com

pwdhash.com

getspyblock.com

safecache.comspoofguard.org