Phishing Technical Controls: Beyond Proofpoint Shelley Rossell | April 5, 2011 Srossell@uchicago. edu
Agenda • • • Introduction Phishing Trends Background Technical Controls: Summary Q&A Downstream Midstream detective Upstream preventive Near the source
Copyright Shelley Rossell 2011. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
Introduction PHISHING: Phishing is a criminal mechanism employing both social engineering and technical subterfuge to steal consumers’ personal identity data and financial account credentials. - http: //www. antiphishing. org This presentation focuses on social engineering phish and cost-free technical controls to help combat them.
Phishing Trends we’ve observed at The University of Chicago: • • • Increase in “URL phish” (directing users to go to a URL) over more primitive “email-reply phish” (requesting users to submit password via email) Increase in fake websites that imitate the look of our webmail login page Higher response rate for such URL phish Higher “churn of concern” (email flood to IT Security) for URL phish Threat of one’s email being terminated continues to trigger some people to respond Education is a key means of combating phish, but technical controls will always play an important role: – Regular turnover of student population – Difficult-to-reach communities of alumni and emeriti
Background on our environment • Disparate email servers and administrative groups around campus (moving to centralized) • Central mail service: – – Exchange email for faculty and staff https: //xmail. uchicago. edu c. Mail (Mirapoint): https: //webmail. uchicago. edu Both login pages globally accessible without VPN All mail from outside goes through Mirapoint spam/phish filters (uses Commtouch database) – Phishers are primarily spoofing the c. Mail (webmail) interface and not Exchange (xmail)
Technical Controls: Downstream • Objective: Clean-up and containment • How learn of phish: Receive abuse complaints about spam from victim’s hacked account • Actions: – Remediate hacked account – Check for other victims: • Review emails to phish dropbox address in email logs • Identify IP address that logged into hacked account and/or used our ‘bait credentials. ’ – Trawl log for other account logins attempted by that IP address – Add IP to watchlist against which we run an hourly check for successful webmail logins • Issue: Manual, time-consuming, after-the-fact clean-up.
Technical Controls: Midstream detective • Objective: Identify compromised accounts before abuse starts • How learn of phish: Phish reported to us, we receive it ourselves, or from the following automated reports: – Top senders from both xmail and cmail systems – Script to identify successful webmail logins from IP watchlist we manually maintain – Alerts on successful logins from particular regions (we use SIEM alerts)
Technical Controls: Midstream detective – Senders with forged envelopes 10 * * root /bin/grep STATUS /var/log/mailmta. log | /bin/grep Authenticated sender | /bin/grep '@gmail|@yahoo|@live|@hotmail|@msn| @myway|@info|@net|@com' | grep -v “<known forged envelopes that are ok> " | sort -r | mailx -e -s "messages with forged envelope" root Example output: Mar 22 19: 08 128. 135. 249. 212 1528567645 MTA. MESSAGE. STATUS AMA 85945 customer-service@paypal. com Authenticated sender xxxxx@uchicago. edu • Actions: Account remediation • Issue: Credentials already compromised Email masquerading as from paypal
Technical Controls: Upstream preventive • Objective: Reduce success of phish attacks • How learn of phish: Phish reported to us, we receive it ourselves, or from automated reports (refer to previous slide) • Actions (depends on if URL or Reply-To phish): – Submit to phishtank. com (if verified, a factor in Open. DNS blackholing it) – Send takedown notice – DNS blackhole the phish domain (includes redirect to IT Security page aimed to educate potential victims) – Block outbound email to Reply-to, dropbox address – Block URL IP on the border router ACLs (very infrequent) • Issue: Only effective if phish recipients attempt to respond when using our campus DNS or mail servers
Our DNS blackhole process • • IT Security submits request to Network Engineering – They add evil domain to BIND, creating a zone for the hostname and providing an A record to a particular web server for this purpose When victim attempts to surf to phish domain: – Victim’s browser redirects to webpage that gives warning (text below) – Information about the request from victim is logged Warning! Request Redirected Your browser was redirected to this website in order to alert you that the site you were attempting to visit is known to contain fraudulent or malicious content. The site would have attempted to trick you into revealing a password or downloading a file that would compromise the security of your system. Please do not attempt to visit that site from a different computer or browser. Instead we encourage you to contact IT Security if you have questions or concerns about this issue: security@uchicago. edu or 773 -702 -2378 (2 -CERT). The University also provides useful information about Safe Computing.
Our DNS blackhole process Log excerpts from redirected. access. log: 205. 208. XXX banjaroya. com - [04/Aug/2010: 09: 32: 04 -0500] "GET / HTTP/1. 1" 301 0 "-" "Mozilla/5. 0 (Macintosh; U; Intel Mac OS X 10. 6; en-US; rv: 1. 9. 1. 11) Gecko/20100701 Firefox/3. 5. 11” 128. 135. XXX. XX www. steinheilenergetik. deﾊ - [02/Nov/2010: 07: 30: 50 -0500] "GET /steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html HTTP/1. 1" 301 0 "-" "Mozilla/4. 0 (compatible; MSIE 7. 0; Windows NT 5. 1; . NET CLR 2. 0. 50727; . NET CLR 3. 0. 4506. 2152; . NET CLR 3. 5. 30729)” 128. 135. XX www. steinheilenergetik. de - [03/Nov/2010: 20: 49: 11 -0500] "GET /steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html HTTP/1. 1" 301 0 "-" "Mozilla/5. 0 (X 11; U; Linux i 686; en-US) Apple. Web. Kit/534. 7 (KHTML, like Gecko) Chrome/7. 0. 517. 43 Safari/534. 7” Actions: We can identify who accessed the page and follow up.
Technical controls: Near the source • Objective: Identify and quash potential phish attacks before they are launched • How learn of phish: Learn of URL likely to be used in phish attack by searching web log data for referrers originating outside our domain Credit: This solution was designed and implemented by Jim Clark, IT Security team, The University of Chicago
Technical controls: Near the source • When a browser requests a file from a webserver, the browser can provide additional information about the request, including what URL told the browser to request it. For example: A request for uchicago. jpg may include the referring page: “https: //webmail. uchicago. edu/login. html” • Assumptions and dependencies – Need a helper file on the login page not used elsewhere – Attackers are lazy and use absolute paths for helper files to mimic login page – Victim’s browser must include the referring page in the request. Default for most browsers but can be disabled in some.
Technical controls: Near the source Helper file not used by other pages
Technical controls: Near the source Excerpt of webmail login page that references the helper file (motd. js): </div> <div id="right-box"> <h 2> c. Mail Tip: </h 2> <SCRIPT LANGUAGE="Java. Script" type="text/javascript" src="https: //nsit. uchicago. edu/common/javascript/motd. js"></SCRIPT> </div> ___________________________________________ Excerpt of web log showing requests for this helper file: 66. 99. xxx. xx - - [01/Nov/2010: 14: 18: 46 -0500] "GET /common/javascript/motd. js HTTP/1. 1" 302 323 "https: //webmail. uchicago. edu/" "Mozilla/4. 0 (compatible; MSIE 6. 0; Windows NT 5. 1; SV 1; Info. Path. 1; . NET CLR 2. 0. 50727)" TLSv 1 RC 4 -MD 5 128. 135. xx - - [01/Nov/2010: 14: 18: 46 -0500] "GET /common/javascript/motd. js HTTP/1. 1" 302 323 "https: //webmail. uchicago. edu/" "Mozilla/5. 0 (Macintosh; U; Intel Mac OS X 10. 5; en-US; rv: 1. 9. 2. 12) Gecko/20101026 Firefox/3. 6. 12" TLSv 1 RC 4 -MD 5 205. 208. xxx - - [01/Nov/2010: 14: 18: 52 -0500] "GET /common/javascript/motd. js HTTP/1. 1" 302 323 "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uch icago. html" "Mozilla/4. 0 (compatible; MSIE 7. 0; Windows NT 5. 1; . NET CLR 1. 1. 4322; . NET CLR 2. 0. 50727; . NET CLR 3. 0. 4506. 2152; . NET CLR 3. 5. 30729; Info. Path. 1)" TLSv 1 RC 4 -MD 5
Technical controls: Near the source #!/usr/local/bin/bash # $Id: repherer 194 2011 -03 -09 18: 47: 54 Z jclark $ # find fake university webmail sites that reference a honey token URL # usage: repherer httpd_logs # output: IP [date] referer # file or URL that identifies user requesting login page honey_uri='motd. js' Helper file used in login page but not in other pages # URLs that would legitimately refer requestor to the honey_uri good_referers='https: //webmail. uchicago. edu/|http: //webmail/|nsit. uchicago. edu’ # find log entries referencing honey_uri then filter for entries that have # "http: as an approximation for finding entries with a referer recorded # then filter out the known good referers. format the results. zgrep -h $honey_uri $* | grep "http: | This patterns seems to be only in ‘referer’ line grep -v $good_referers | Filter out expected referring URLs awk '{print $1, $4, "]", $11}'
Technical controls: Near the source $. /repherer <web log> 128. 135. 59. XX [29/Jul/2010: 18: 03 ] http: //banjaroya. com/webmail. uchicago. edu/ attacker testing fake site. . 41. 155. 110. 149 [01/Nov/2010: 13: 26: 34 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 128. 135. 177. XXX [01/Nov/2010: 14: 18: 22 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 205. 208. 52. XXX [01/Nov/2010: 14: 18: 52 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 165. 68. 10. XXX [01/Nov/2010: 14: 19: 02 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 165. 68. 218. XX [01/Nov/2010: 14: 19: 07 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 128. 135. 187. XXX [01/Nov/2010: 14: 20: 18 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 165. 68. 10. XXX [01/Nov/2010: 14: 20: 31 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 128. 135. 32. XXX [01/Nov/2010: 14: 21: 34 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 128. 135. 53. XXX [01/Nov/2010: 14: 22: 18 ] "http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html" 128. 135. 117. XXX [01/Nov/2010: 14: 25: 45 ] http: //www. steinheilenergetik. de/steinenergetik/tl 1/system/modules/df. Gallery/uchicago. html. . Our users that tried to go to phish URL 95. 91. 137. 113 [28/Feb/2011: 15: 58: 20 ] "http: //localhost/Tom/webmail. uchicago. htm" 95. 91. 137. 113 [28/Feb/2011: 16: 00: 28 ] "http: //localhost/Tom/TOM-Login/webmail. uchicago. htm" 95. 91. 137. 113 [28/Feb/2011: 16: 30: 07 ] "http: //localhost/Tom/webmail. uchicago. htm" AS | IP 33776 | 41. 155. 110. 149 31334 | 95. 91. 137. 113 attacker likely creating fake uchicago webmail login page | CC | Registry | Allocated | AS Name | NG | afrinic | 2008 -12 -18 | STARCOMMS-ASN | DE | ripencc | 2008 -12 -15 | KABELDEUTSCHLAND-AS Kabel Deutschland Breitband Service Gmb. H
Technical Controls: Near the source • Benefits: – Possible to preempt and defuse phish attack – Reduction in churn of concern if site offline or blackholed • Actions: – Submit to phishtank (Open. DNS blackhole) – Takedown notice – DNS blackhole the domain – See suspicious attacker IP and look for it in the logs – If URL pattern imitates other university sites, warn others • Improvements: Automate process to run regularly, send email alerts, submit to phishtank, and run other checks • Variation: Look for login pages if attacker redirects to real page
Technical Controls: Near the source • Objective: Identify and quash potential phish attacks before they are launched • Proactive: Complement reactive blackhole process with a blackhole domain list or feed from trusted source(s), if possible. • A few examples: • http: //www. more. net/blackhole_dns • http: //www. malwaredomains. com/ • http: //www. surbl. org/
Phishing Technical Controls: Summary Technical Control Where in process Benefit Issue Review logs for other victims Downstream Can identify other victims based on attacker IP and phish information Credentials already compromised and used for abuse Automated reports, e. g. : - Top email senders - IP watchlist logins - Geographic-based alerts - Forged envelopes Midstream detective Identify compromised accounts before abuse starts Credentials already compromised Block replies to drop-box or blackhole the domain; submit takedown notices Upstream preventive Reduce success of phish attacks Potential victims must use our mail or DNS servers Illegitimate referrers for mail login helper file in web logs Upstream near source May allow us to block responses and takedown phish URL site before phish sent Relies on browsers to pass referrers, loginpage-specific helper file, lazy attackers Blackhole DNS feed Upstream near source Allows us to block likely malicious URLs proactively Can be thousands of domains; buy-in
Phishing Technical Controls • Q&A
THANK YOU srossell@uchicago. edu
Скачать презентацию Phishing Technical Controls Beyond Proofpoint Shelley Rossell
f7c46604c467da4c38d7628b562159a6.ppt