Last week in part 1 we looked at some rather extreme measures for keeping that demeritorious duo, spam and viruses, off our servers. Today we’ll look at how to secure your users’ email clients. The reason for employing layers of security at both the server and client level is simple, Grasshopper; do not depend solely on border defenses or the succulent soft underbelly of your network will remain at risk.
First Choose a Sensible Mail Client
I’m sure you’ve heard it a million times — “Don’t use Outlook or Outlook Express.” It’s darn good advice. Outlook is useful on an intranet, when you need the full scheduling, contacts, document sharing, and other groupware features. For Internet mail — well, its record speaks for itself. For those who really must use it, see Resources for tips on making Outlook not quite so insecure.
If all you need is a POP or IMAP mail client for Windows, Eudora, Pegasus, and Mozilla Mail are excellent choices. They are far less open to exploits, and they use generic mailbox formats instead of the “seekrit” proprietary formats of Outlook/Outlook Express. This makes disaster recovery and importing/exporting a lot easier, because the files can be read as plain text.
The Linux world is also full of excellent mail readers — Kmail, Balsa, Evolution, and Mozilla Mail, as well as the powerhouses Mutt and Pine for the über-guru, non-GUI console folk. What’s nice about all of these is that in addition to having great feature sets, they are genuine standalone mail clients. In other words, you don’t have to mess with a web browser to configure security settings.
Securing an Email Client
Spammers and virus writers are doing some incredibly creative – and malicious – things with HTML. Here are some simple tweaks that will make any mail reader more secure:
- Filter messages that are greater than 100 kilobytes; keep them on the server until you can look at them. Most commercial email accounts include Webmail, so it is easy to examine them before they reach your system. If you run the mail server on your end, it’s even easier.
- Turn off HTML. Make the default plain text; neither an HTML spewer nor reader be. While Kmail has a nice feature that lets you turn on HTML for a single message, most mail readers are all-or-nothing.
- Do not allow messages to load external references from the Internet.
- Do not allow ‘receive’ or ‘read’ confirmations to be sent.
The last two items may not be a configurable option on all mail clients, and of course Mutt and Pine, being ASCII mail readers, will not render HTML. There’s nothing to gain in any case by allowing external references to load — it’s just a big hole to let mischief in. (OK, so you’re maybe missing out on a “rich media experience. I’m soooo sorry.)
‘Receive’ or ‘read’ confirmations are up to you, although I’ve personally never seen the value in enabling them. Confirmations to spam messages only serve to let the spammers know they’ve found live, working addresses, and that you may even be foolish enough to open and read their spew. (And even if spam were not an issue, I prefer keeping the tried and true “The Internet must have eaten your message” option open.)
How to Find Malicious Code
Studying a spam or virus message in plain text is a fascinating exercise in misplaced ingenuity. (If only that energy were devoted to good and useful activities!) Be sure to read suspect HTML messages in plain text only! A rich source of spam messages to study is the Usenet group news.admin.net-abuse.sightings.
A person can spend a lot of time looking for Web Bugs, as they are sneaky little buggers. Here’s one example from The Privacy Foundation:
<img width=’1′ height=’1′ src=”http://www.m0.net/m/logopen02.asp? vid=3&catid=370153037&email=SMITHS %40tiac.net” alt=” “><IMG SRC= “http://email.bn.com/cgi-bin/flosensing? x=ABYoAEhouX”>
Making matters worse, if you happen to enter personally identifiable information on any of the co-conspirator sites, all of them will be able to link your activities to your name. There is some debate about whether Web bugs are evil, but anything that is so sneaky is highly suspect to me. I’ve yet to see any disclosure on sites that use these, and of course spammers aren’t going to say anything.
Decoding Malicious HTML
Much of what you see is an attempt to evade spam filters by breaking up key words with HTML tags and comments. Newer spam filters are not fooled.
<div align=”center”><!–9p1t5lyvnvhp–><font size=”+2″><strong>G<!–d14my1181r–>ene<!–xgjs4fd0yt4n18–>ric Vi<!–h5uxcu5oqa9–>ag<!–2cxnzp1vdkj3c–>ra </strong></font></div>
See the original here. It’s a Viagra spam, in case you were wondering.
This example uses HTML entities to hide words (see The HTML Coded Character Set for the complete list of HTML entity codes):
Watch Dogs slurp
And the following is Unicode, indicating the character set is not installed on your system:
I see a lot of these from China. Yeah, why not flood the world with this stuff — you never know who will be able to read it and wind up as a happy customer. Sure.
Scripting, Spoofing, and Phishing
Here is a PayPal phish. The person who posted this gave a lot of useful information. Most of the code was first copied directly from a real PayPal page, and then hidden fields, Web bugs, and redirects were added. This particular exercise in sheer chutzpah contains a nice, handy-dandy form full of drop-down boxes that asks for all kinds of neat stuff: your PayPal account information, bank account, credit card number, etc. The safest way to view this in full HTML glory is to copy the code to a text editor, save it as an .html file, and then view it in an offline Web browser. Do not be connected to the Internet!
Spoofing doesn’t even need fancy scripting; look at this little honey from another PayPal phish:
Notice how the URL is spoofed — the label looks like a PayPal URL, but the real link is http://www.exme.us/~x. That’s right, you cannot even trust clicking links. Thanks, spammers!