1 / 32

Client-side defenses against web-based identity theft

This project aims to develop browser plug-ins, SpoofGuard and PwdHash, to detect and prevent phishing attacks, improving browser password management and reducing the risk of web-based identity theft.

lschmidt
Download Presentation

Client-side defenses against web-based identity theft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Students: Robert Ledesma, Blake Ross, Yuka Teraguchi Faculty: Dan Boneh and John Mitchell Stanford University PORTIA Project Client-side defenses against web-based identity theft

  2. password? User clicks on email link to go to badguy.com. Information is sent to the bad guy. User thinks it is ebay.com, and enters eBay username and password. Phishing Attack Spam email: “There is a problem with your eBay account.”

  3. Sample phishing email

  4. How does this lead to spoof page? • Link displayed • https://www.start.earthlink.net/track?billing.asp • Actual link in html email • source:https://start.earthlink.net/track?id=101fe8439 8a866372f999c983d8973e77438a993847183bca43d7 ad47e99219a907871c773400b8328898787762c&url= http://202.69.39.30/snkee/billing.htm?session_id=8495... • Website resolved to • http://202.69.39.30/snkee/billing.htm?session_id=8495...

  5. Spoof page http://202.69.39.30/snkee/....

  6. Magnitude of problem • Fastest growing crime on the Internet. • Primary targets: attacks/month (2004) http://www.antiphishing.org

  7. Properties of Spoof Sites • Ask for user input, e.g. password. • Some ask for CCN, SSN, mother’s maiden name, … • HTML copied from honest site • Contain links to the honest site • Logos from honest site. Copied jpg/gif file, or link to honest site • Can contain revealing mistakes • Clever spoof pages contain Javascript to fool user. • Short lived • Blacklisting spoof sites has limited success. • HTTPS uncommon

  8. Thanks!  Robert Rodriguez Chris Von Holt Alissa Cooper  Tom Pageler  Greg Crabb Many more …

  9. This talk: SpoofGuard What can we do about phishing? • Spam filter: • Phishing starts with email, so stop it there. • Non-trivial: phishing emails look like ordinary email. • Browser-side methods (plug-ins) • Detect spoof web site. Warn user. • Improve browser password management. • Server-side methods: • Use strong user authentication instead of pwds. • Certificates or security tokens.

  10. Our project at Stanford • Two browser plug-ins available for download: • SpoofGuard: • Alerts user when browser is viewing a spoofed web page. • Uses variety of heuristics to identify spoof pages. • PwdHash: • Simple mechanism for improving password management by the browser. • Will SpoofGuard solve the phishing problem? • As likely to end phishing as first virus scanner was to end viruses • A new type of anomaly detection problem

  11. SpoofGuard:Detect Phishing Web Sites http://crypto.stanford.edu/SpoofGuard

  12. SpoofGuard Browser Plug-in • Compute spoof index: • Weighted sum of several spoof measures • Depends on current page and history • Provides two forms of information: • Passive stoplight in toolbar: green, yellow, red • Active pop-up when necessary • Stop outgoing information to malicious web site • Challenges: • Must be easy for novice users. • Detect malicious pages • Minimize false alarms

  13. Stateless Page Evaluation • URL Check: • Similar to well known site • www.ebay-fixit.com • www.ebau.com • IP address instead of host name • http://123.123.123.123/ • Other tricks • www.ebay.com@123.123.123.123 • Use reverse DNS to find domain if IP address • Image Check: • Is image associated with different domain in image-domain database

  14. Stateless Page Evaluation II • Link Check: • Run URL check on links on the page • If significant fraction fail, raise alert • Password Check: • Pages with password field are more suspicious than the one without • Check for HTTPS and valid certificate

  15. Stateful Page Evaluation • History Check: • Site is assumed OK if in user’s history file • Very important for reducing false alarm rate • Domain Check: • Is current domain “similar” to a domain in the history list? • Email Check: • Suspicious if page is referred by email link

  16. POST: user_name=ice&password=cream Suspicious server User POST Data Evaluation • Intercepts and checks POST data • Keep hashed <domain, user, password> triples • If known user & password are sent to different domain, raise alert level • Exception for search engines • High alert: warn user and allow to cancel operation

  17. SpoofGuard User Interface • SpoofGuard is added to IE tool bar • Traffic light • Report green, yellow, red altert level • Pop-up as method of last resort

  18. Evaluation of SpoofGuard • Detect sample spoofs • Tested on 12 spoofs from SF ECTF • Acceptable false alarm rate • Used ourselves for several weeks • Can get false alarms on first visit to site • SpoofGuard learns which sites you trust • Does not popup on subsequent visits • Negligible performance impact But: Clever phisher can defeat most tests

  19. PwdHash: Improved Pwd Mgmt http://crypto.stanford.edu/PwdHash

  20. The common pwd problem • Web users use the same username/password at many sites. • Users use their banking pwd at low security sites. • The problem: break-in to low security site reveals banking username/passwords. • Ideal solution: strong auth. protocols (SecureID/PKI) • Unlike pwd, requires HW or has limited mobility.

  21. A Simple Solution • Browser plug-in that converts a user’s pwd into a unique pwd per site. • Locate all pwd HTML elements on page:<INPUTTYPE=password NAME=pass> • Whenever focus leaves a password field, replace contents of field with HMACpwd(domain-name) • Password hash is sent to web site instead of pwd. • (some) Protection against phishing: • Spoof site only sees hash of user’s pwd.

  22. Pwd Hashing – an old idea • Hash pwd with realm provided by remote site: • HTTP 1.1 Digest Authentication • Kerberos 5 • Hash pwd with network service name: • Gabber, Gibbons, Matyas, Mayer [FC ’96]. Proxy. • Abadi, Bharat, Marais [PTO ’97] • Challenge: implementing in a modern browser.

  23. Plug-in Challenges • Pwd reset after plug-in install • Javascript attacks • What salt to use in hash? • How to encode resulting hash? • When to compute hash? • Internet Café • Dictionary attacks • Design goal: transparent to user.

  24. Problem 1: pwd reset • After install, requires users to reset their pwds. • On pwd reset page, plug-in must not hash old pwd. • Plug-in identifies pwd reset page as having three pwd fields. • Plug-in does not hash first pwd field. (turns blue) • Plug-in remembers to hash all pwd fields on future invocations of this reset page • To disable/toggle hashing: double-click in pwd field. • Problem: phishers could create a spoof pwd reset page and obtain pwds in the clear. • Plug-in warns user when it sends pwd un-hashed.

  25. Problem 2: Cafe’s • Users cannot install plug-in at Internet Cafe’s. • We provide a web site for remote hashing:http://crypto.stanford.edu/PwdHash/ • Hash computed in Javascript. • Resulting hash copied into clipboard.

  26. Problem 3: Javascript attacks • Malicious site can create Javascript to steal user’s unhashed password. • Record all key-strokes sent to page • Change target-domain-name on submit • Mask regular text field as a password field • Even worse: as each keystroke is typed into field, send to evil site. (?)

  27. Javascript attacks (cont.) • Defense 1: Keyboard intercept. • System traps all keyboard events to window. • If keystroke intended for pwd field, replace with ‘%’ • Browser never sees pwd. • On ‘BeforeNavigate2’ event, replace ‘%%%’ in POST data with hashed pwd. • Defense 2: key-stream monitor. • System records all passwords user types (hashed). • System traps all keyboard events to window. • If key-stream ever contains a pwd not in pwd field, alert user.

  28. Problem 4: what salt to use? • For few sites, domain of pwd reset page  domain of pwd use pagepassport reset page = services.passport.netpassport use page = login.passport.net • Incorrect pwd-hash is registered at site. • Config file tells plug-in what salt to use and how to encode hash: <pwdhash domain=“*.com” tail=2 encode=1> <pwdhash domain=“*.co.uk” tail=3 encode=1>

  29. Problem 5: Dictionary attacks • Main point: low security site never sees user’s pwd. • Dictionary attacks: • After phishing or break-in to low security site,attacker obtains pwd hashes. • Attacker can attempt dictionary attack on hashes. • Succeeds on  15% of pwds (unlike 100% today) • Fundamental limitation of pwd authentication. Unavoidable when user’s key is low-entropy. • Defense: plug-in enables user to specify a global plug-in pwd used to strengthen all pwd hashes. • Defense against dict. attacks for savvy users.

  30. Alternative designs • Better security against Javascript attacks: • Modify pwd UI: 1. User hits ctrl-P in password field. 2. Plug-in displays password dialog box. 3. User enters password into dialog box. • Plug-in embeds hashed-pwd directly into out-going POST data. (BeforeNavigate2 event) • Javascript on page can’t see pwd and cannot spoof dialog box. • Downside: confusing to users. • Better salt for pwd: Get salt from SSL certificate. • Not possible with current plug-in support in IE. • Microsoft could do this …

  31. Try it out! • Plug-ins continue to evolve and improve: • Easier deployment and use. • Proxy-based solutions (not browser plug-ins) • Strengthen spoof page identification. • Deployment through Mozilla and billeo. http://crypto.stanford.edu/SpoofGuard

  32. crypto.stanford.edu/SpoofGuard

More Related