E-mail Security – Still an Issue

While scam e-mails are often fairly easy to spot, it’s not a given that a ruse is going to be executed in text-only, poorly written english by a supposed Nigerian prince. Malware is big business these days, and e-mail scams are getting more professional. Take this example as detailed by Panda Labs. From start to finish it’s a perfect impersonation of an IRS e-mail, insofar as it can be for requesting detail that the IRS would not request over e-mail.

The main focus I’d like to address is that while on the Internet you can look at a web-address, and if it’s over TLS/SSL, you essentially have a guarantee that it’s the site you requested (if it says https://mail.google.com you known you’re at Gmail, for example), the same is not true of e-mail. It’s not uncommon for scam e-mails to just send from a random free e-mail account, but that’s the equivalent of the blatant Nigerian 419 scam. More professionally an e-mail can say it’s from irs.com, whitehouse.gov, bankofamerica.com or anywhere else. E-mail headers are spoofable. You can change any of that information at will, by design. For example, take a look at how easy it is to do in PHP

$to      = 'sucker@gmail.com';
$subject = 'Your account information';
$message = "Don't be a pussy, we're legit";
$headers = 'From: support@wellsfargo.com' . "\r\n" .
	   'Reply-To: support@wellsfargo.com' . "\r\n";

mail($to, $subject, $message, $headers);

As simply as that, you can send out an e-mail with false information in the header. There’s no point at which the headers are verified for consistency due to the nature of the protocol. They’re a convenience, not an assurance. The reason this does not work with websites is twofold. In general, the server does not request you, you request it. Someone can’t simply spoof a server response and send it to you anytime. It is possible, though, to act as a man-in-the-middle and intercept your request to a website and respond fraudulently. This is a genuine concern at public Wi-Fi hotspots, and less-so on private wired networks.

The protection to this is the aforementioned TLS/SSL which is an encrypted connection. The connection is negotiated based on IP address and a certificate verified by a root authority. For example, say Google gets a certificate from VeriSign at IP address 22.33.44.55. If a man-in-the-middle attempts to intercept the request, the TLS connection will fail and you’ll get a warning. IP addresses cannot be spoofed for a TCP/IP connection (though they can be spoofed in individual packets) due to what’s referred to as a three way handshake. When you request a connection to a web server, you send a SYN packet containing your IP address. The server subsequently responds to that packet with a SYN-ACK packet, sent to the IP address in the SYN packet — if it is spoofed, it will go to the wrong address and you won’t receive it. This will cause the connection to fail, because in order to complete the transaction, you must respond to that specific SYN-ACK packet with a SYN-ACK-ACK packet to confirm the connection.

Why not TLS for e-mail? Well, again, web-pages are received upon request, whereas e-mails are unsolicited; however, there is the option of assymetric e-mail signing such as OpenPGP which allows you to encrypt or sign your e-mails with a signature verifying the identity of the sender. This is not part of the e-mail specification and limited in scope of use thereby limited its usefulness.

Furthermore, it’s not just a matter of responding to e-mails that is a problem, it’s doing anything with the contents therein, including following links or downloading attachments. In great part by Adobe’s poor security practices combined with the profileration of their products, malicious PDF and Flash documents have become a primary vector of attack. There have been a slew of vulnerabilities in Adobe Reader (and FoxIt reader oft also affected) of late that allow execution of arbitrary code, meaning just by opening a PDF document, you can be infected. This is largely, though not entirely, thanks to Adobe’s ridiculously stupid idea to include JavaScript as a part of PDF files, meaning you can have scripting in PDFs. You can, and should, disable this in your settings (or better yet, not use Adobe Reader. Ever.).

Flash is embedded in web-pages, and will continue to be a larger attack target as time progresses. Following links can lead you to sites with malicious Flash files embedded, again meaning arbitrary code could potentially be executed without your knowledge or approval. If you’re not on the latest version, the more likely there is for an issue.

The attack vector isn’t necessarily just some random person, either. As detailed in a recent Security Now episode, just because it’s from someone you know doesn’t mean you can trust it, even if the header is not spoofed. One of the most lucrative assets a blackhat can get his hands on is an e-mail address. If someone gets into the e-mail of a friend or family, he can then use the information there to try to coerce you into sending money. Their life is contained in that e-mail account, likely years worth of personal information; from that, it isn’t difficult to be convincing.

Lastly, e-mails themselves can include HTML and display like webpages. In Outlook, for example, you get a preview pane such that if you just click the title of an e-mail, the contents are displayed immediately below. Convenient, but a terrible idea. Again, web-pages can contain exploits. You can, and should, switch to text-only display of e-mails.

It’s almost a cliche to warn about e-mail and the dangers of attachments, but it’s more of a problem now than ever. It’s not just don’t download and run .exe attachments anymore.

E-mail safety in summary:

• Do not trust any unexpected e-mail
• Do not trust e-mail headers
• Switch to text-only mode in e-mail
• Verify via other means any request for money, even if you know the person
• Never open unexpected attachments
• Do not open spam
• If you open spam, do not reply

All that, or, you know, switch to Linux.