context-aware phishing attacks and client-side defenses collin jackson stanford university
Post on 20-Dec-2015
220 views
TRANSCRIPT
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