Jj

1. CAP6135: Malware and Software
Vulnerability Analysis
Spam and Phishing
Cliff Zou
Spring 2012

2. 2
Acknowledgement
 This lecture uses some contents from the lecture notes
from:
 Dr. Dan Boneh (Stanford): CS155:Computer and Network
Security
 Jim Kurose, Keith Ross. Computer Networking: A Top Down
Approach Featuring the Internet, 5th edition.

3. 3
Electronic Mail
Three major components:
 user agents
 mail servers
 simple mail transfer protocol: SMTP
User Agent
 a.k.a. “mail reader”
 composing, editing, reading mail
messages
 e.g., Eudora, Outlook, elm,
Netscape Messenger
 outgoing, incoming messages
stored on server
user mailbox
outgoing
message queue
mail
server
user
agent
user
agent
user
agent
mail
server
user
agent
user
agent
mail
server
user
agent
SMTP
SMTP
SMTP

4. 4
How email works: SMTP
(RFC 821, 1982)
 Some SMTP Commands:
MAIL FROM: <reverse-path>
RCPT TO: <forward-path>
RCPT TO: <forward-path>
If unknown recipient: response “550 Failure reply”
DATA
email headers and contents
 Use TCP port 25 for connections
.
Repeated
for each
recipient

5. 5
Sample fake email sending
S: 220 longwood.cs.ucf.edu
C: HELO fake.domain
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <czou@cs.ucf.edu>
S: 250 czou@cs.ucf.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: from: “fake man” <fake@fake.fake.fake>
C: to: “dr. who” <who@who>
C: subject: who am I?
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 longwood.cs.ucf.edu closing connection

6. 6
Try SMTP interaction for yourself:
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
 “mail from:” the domain may need to be existed
 “rcpt to:” the user needs to be existed
 A mail server may or may not support “relay”
 CS email server supports relay for campus network
 “from:” “to:” “subject:” are what shown in normal
email display

7. Using Telnet
 On department eustics Linux machine:
 telnet longwood.cs.ucf.edu 25
 In telnet interaction, “backspace” is not supported.
You can type “ctrl+backspace” to erase previous two
characters
 On Windows 7 machine:
 Telnet is not installed by default, check this tutorial
for install:
 http://technet.microsoft.com/en-
us/library/cc771275%28v=ws.10%29.aspx
7

8.  Outside campus network, department email server does
not accept:
 You need to first setup VPN to campus network, then use telnet
 How to set up VPN:
 https://publishing.ucf.edu/sites/itr/cst/Pages/VpnHelp.aspx
8

9. 9
Email in the early 1980’s
Network 1
Network 2
Network 3
Mail
relay
Mail
relay
sender
recipient
• Mail Relay: forwards mail to next hop.
• Sender path includes path through relays.

10. Why Email Server Support Relay?
 Wiki tutorial:
 http://en.wikipedia.org/wiki/Open_mail_relay
 Old days network constraint makes it necessary
 Email agent uses SMTP to send email on behalf of a user
 The user could choose which email address to use as the sender
 Email server supports email group list:
 The “sender” shown in email is the group list address, but the real
sender is a different person
 Closing Relay:
 Messages from local IP addresses to local mailboxes
 Messages from local IP addresses to non-local mailboxes
 Messages from non-local IP addresses to local mailboxes
 Messages from clients that are authenticated and authorized
10

11. 11
Spoofed email
 SMTP: designed for a trusting world …
 Data in MAIL FROM totally under control of sender
 … an old example of improper input validation
 Recipient’s mail server:
 Only sees IP address of direct peer
 Recorded in the first From header

12. 12
The received header
 Sending spoofed mail to myself:
From someone@somewhere.com (172.24.64.20) ...
Received: from cs-smtp-1.stanford.edu
Received: from smtp3.stanford.edu
Received: from cipher.Stanford.EDU
 Received header inserted by relays --- untrustworthy
 From header inserted by recipient mail server
From
relays

13. 13
Spam Blacklists
 RBL: Realtime Blackhole Lists
 Includes servers or ISPs that generate lots of spam
 spamhaus.org , spamcop.net
 Effectiveness (stats from spamhaus.org):
 RBL can stop about 15-25% of incoming spam at SMTP
connection time,
 Over 90% of spam with message body URI checks
 Spammer goal:
 Evade blacklists by hiding its source IP address.

14. Spamming techniques

15. 15
Open relays
 SMTP Relay forwards mail to destination
1. Bulk email tool connects via SMTP (port 25)
2. Sends list of recipients (via RCPT TO command)
3. Sends email body --- once for all recipients
4. Relay delivers message
 Honest relay:
 Adds Received header revealing source IP
 Hacked relay does not

16. 16
Example: bobax worm
 Infects machines with high bandwidth
 Exploits MS LSASS.exe buffer overflow vulnerability
 Slow spreading:
 Spreads on manual command from operator
 Then randomly scans for vulnerable machines
 On infected machine: (spam zombie)
 Installs hacked open mail relay. Used for spam.
 Once spam zombie added to RBL:
 Worm spreads to other machines

17. 17
Open HTTP proxies
 Web cache (HTTP/HTTPS proxy) -- e.g. squid
 To spam: CONNECT SpamRecipient-IP 25
SMTP Commands
Squid becomes a mail relay …
Squid
Web
Cache
CONNECT xyz.com 443
ClientHello Web
Server
xyz.com
URL: HTTPS://xyz.com
ClientHello
ServerHello
ServerHello

18. 18
Finding proxies
 Squid manual: (squid.conf)
acl Safe_ports port 80 443
http_access deny !Safe_ports
 URLs for other ports will be denied
 Similar problem with SOCKS proxies
 Some open proxy and open relay listing services:
 http://www.multiproxy.org/
http://www.stayinvisible.com/
http://www.blackcode.com/proxy/
http://www.openproxies.com/ (20$/month)

19. 19
Open Relays vs. Open Proxies
 HTTP proxy design problem:
 Port 25 should have been blocked by default
 Otherwise, violates principal of least privilege
 Relay vs. proxy:
 Relay takes list of address and send msg to all
 Proxy: spammer must send msg body to each recipient through
proxy.
 zombies typically provide hacked mail relays.

20. 20
Thin pipe / Thick pipe method
 Spam source has
 High Speed Broadband connection (HSB)
 Controls a Low Speed Zombie (LSZ)
 Assumes no egress filtering at HSB’s ISP
 Hides IP address of HSB. LSZ is blacklisted.
Target
SMTP
Server
HSB
LSZ
TCP handshake
TCP Seq #s
SMTP bulk mail
(Source IP = LSZ)

21. 21
Bulk email tools (spamware)
 Automate:
 Message personalization
 Also test against spam filters (e.g. spamassassin)
 Mailing list and proxy list management

22. 22
Send-Safe bulk emailer

23. Anti-spam methods

24. 24
The law: CAN-SPAM act (Jan. 2004)
 Bans false or misleading header information
 To: and From: headers must be accurate
 Prohibits deceptive subject lines
 Requires an opt-out method
 Requires that email be identified as advertisement
 ... and include sender's physical postal address
 Also prohibits various forms of email harvesting
and the use of proxies

25. 25
Effectiveness of CAN-SPAM
 Enforced by the FTC:
 FTC spam archive spam@uce.gov
 Penalties: 11K per act
 Dec ’05 FTC report on effectiveness of CAN-SPAM:
 50 cases in the US pursued by the FTC
 No impact on spam originating outside the US
 Open relays hosted on bot-nets make it difficult
to collect evidence
http://www.ftc.gov/spam/

26. 26
Sender verification I: SPF
(sender policy framework)
 Goal: prevent spoof email claiming to be from HotMail
 Why? Bounce messages flood HotMail system
DNS
hotmail.com:
SPF record:
64.4.33.7
64.4.33.8
Recipient
Mail
Server
(MUA)
Sender
MAIL FROM
xyz@hotmail.com
hotmail.com
64.4.33.7
64.4.33.8
Is SenderIP
in list?
More precisely: hotmail.com TXT v=spf1 a:mailers.hotmail.com -all

27. 27
Sender verification II: DKIM
 Domain Keys Identified Mail (DKIM)
 Same goal as SPF. Harder to spoof.
 Basic idea:
 Sender’s MTA signs email
 Including body and selected header fields
 Receiver’s MUA checks signature
 Rejects email if invalid
 Sender’s public key managed by DNS
 Subdomain: _domainkey.hotmail.com

28. 28
Graylists
 Recipient’s mail server records triples:
 (sender email, recipient email, peer IP)
 Mail server maintains DB of triples
 First time: triple not in DB:
 Mail server sends 421 reply: “I am busy”
 Records triple in DB
 Second time (after 5 minutes): allow email to pass
 Triples kept for 3 days (configurable)
 Easy to defeat but currently works well.

29. 29
Puzzles and CAPTCHA
 General DDoS defense techniques
 Puzzles: slow down spam server
 Every email contains solution to puzzle where
challenge = (sender, recipient, time)
 CAPTCHA:
 Completely Automated Public Turing test to tell Computers and
Humans Apart
 Every email contains a token
 Sender obtains tokens from a CAPTCHA server
 Say: 100 tokens for solving a CAPTCHA
 CAPTCHA server ensures tokens are not reused
 Either method is difficult to deploy.

30. SpamAssasin
 Wiki tutorial:
 http://en.wikipedia.org/wiki/SpamAssassin
 Mainly a rule-based spam filter
 Many rules to give scores for all fields in an email
 Email header, special keywords in email, URLs in email, images in
email, …..
 Final decision is the combined score compared with a threshold
 Has false positive (treat normal as spam), and false negative
(treat spam as normal)
 False positive is very damaging!
 Nobody wants to lose an important email!
 Also contains Bayesian filtering to match a user’s
statistical profile
 Need known “ham” and “spam” email samples for training

30

31. Part II:
Phishing & Pharming

32. 32
Oct. 2004 to July 2005 APWG

33. 33

34. 34
Note: no SSL. Typically: short lived sites.

35. 35
Common Phishing Methods
 Often phishing sites hosted on bot-net drones.
 Move from bot to bot using dynamic DNS.
 Use domain names such as:
www.ebay.com.badguy.com
 Use URLs with multiple redirections:
http://www.chase.com/url.php?url=“http://www.phish.com”
 Use randomized links:
 http://www.some-poor-sap.com/823548jd/

36. 36
Industry Response
 Anti-phishing toolbars: Netcraft, EBay, Google, IE7
 IE7 phishing filter:
 Whitelisted sites are not checked
 Other sites: (stripped) URL sent to MS server
 Server responds with “OK” or “phishing”

37. 37
Pharming
 Cause DNS to point to phishing site
 Examples:
1. DNS cache poisoning
2. Write an entry into machine’s /etc/hosts file:
“ Phisher-IP Victim-Name ”
 URL of phishing site is identical to victim’s URL
 … will bypass all URL checks

38. 38
Response: High assurance certs
 More careful validation of cert issuance
 On browser (IE7) :
… but most phishing sites do not use HTTPS

39. 39
Other industry responses:
BofA, PassMark
ING bank login

40. 40
Industry Response:
Bank of Adelaide

41. 41
ING PIN Guard

42. 42
T.G.s: The next phishing wave
 Transaction generation malware:
 Wait for user to login to banking sites
 Issue money transfer requests on behalf of user.
 Reported malware in UK targeting all four major banks.
 Note: These are social engineering attacks.
Not just a windows problem.

43. 43
Some ID Protection Tools
 SpoofGuard: (NDSS ’04)
 Alerts user when viewing a spoofed web page.
 Uses variety of heuristics to identify spoof pages.
 Some SpoofGuard heuristics used in
eBay toolbar and Earthlink ScamBlocker.
 PwdHash: (Usenix Sec ’05)
 Browser extension for strengthening pwd web auth.
 Being integrated with RSA SecurID.

44. 44
Password Hashing (pwdhash.com)
 Generate a unique password per site
 HMACfido:123(banka.com)  Q7a+0ekEXb
 HMACfido:123(siteb.com)  OzX2+ICiqc
 Hashed password is not usable at any other site
Bank A
Site B
pwdA
pwdB
=

45. Our New Proposed Approach: PwdIP-Hash
 Problem of PwdHash:
 cannot deal with Phishing attack
 Basic Idea: User password is first hashed with remote
server’s IP address + domain name, then transmit to
the remote server
 Reason: a remote server cannot lie about its IP address
 TCP connection has already set up, very hard to lie
 Result: The remote server receives a hashed password
 The real server has the plain password and can verify
 The phishing server cannot use the hashed password for login
 See our prototype at:
 http://www.cs.ucf.edu/~czou/PwdIP-Hash/
 Paper published in conference IEEE NCA 2010.
45

46. 46
Take home message
 Deployed insecure services (proxies, relays)
 Quickly exploited
 Cause trouble for everyone
 Current web user authentication is vulnerable
to spoofing
 Users are easily fooled into entering password
in an insecure location