Turnkey Email Security

Email remains the most common route for hackers to get into allegedly secure networks. Besides with many aspects of security, it remains a weak link in the chain when it comes to privacy and anonymity.

Too much security threat modeling focuses on least likely scenarios. The most open and shortest path into a network is by email. Why climb over fences composed of TLSv1.3, IPSec tunnels and AES256? Just ask any ransomeware extortionist.

The problem goes back decades. There was a weekday in 1999 or 2000 when an AM radio station shrieked an early morning warning about some email attachment initiating a network attack. It was already shutting down infrastructures globally before breakfast in New York. A user would click to open the attachment, but then "nothing" would happen. But something did happen. Some little JavaScript or Visual Basic application took over from there, and began its evil agenda. Users ignoring an early morning warning paper memo would say "But nothing happened when I tried to open an attachment."

It was I who heard the radio warning while in the shower, it was I who wrote and distributed the memo and yes, it was I who fielded those user inquiries.

But as the saying goes, electronic security is the war in which civilians are in the trenches, and such behavior is expected.

There is a simple solution to many phishing attacks, with the embedded scripts and all the payloads. It's a solution that can be safely placed in the hands of non-technical "civilians."

Less is definitely more when it comes to this solution. And no, there is no patent pending on this humble offer that could save millions of your local currency and days of headaches for the technical staff.

A brief warning though: your marketing department won't be fond of it. And neither will marketing departments external to your entity.

Email clients slowly took on the interfaces of graphical editing applications, such as Microsoft Word, a very long time ago. It might have been something like Pegasus on Windows, or some other early graphical email program, that shifted email from a basic text interface to something more expressive and, well, colorful on multiple levels.

Before that, email was merely a tool to send and receive basic text, formatted in standard ASCII. What you saw was what you got. If you wanted to change the text colors, the only option was to change the monochrome monitor to another manufacturer. All the email content was in front of you including headers with the transport information. There was no obscuring of the sender or the contents.

HTML arose as a formatting syntax for web site pages, as the internet moved from the basic text interfaces for tools like Gopher and moved into what we all now know as the World Wide Web employing HTTP.

The problem with email really started when that HTML formatting, with the colored text, configurable fonts and dazzling graphics, entered email applications, into what some of us call mail user agents, or MUAs.

Whether Microsoft's Outlook, Mozilla's Thunderbird, Apple Mail or some web-based systems such as GMail, or any phone-based MUAs, HTML formatting for email is the norm. And there are plenty of users who will scream and cry if someone took it away.

But within that marvelous formatting hides a whole lot of other things.

Just as the cloud obscures the hardware and network layers for DevOps staff, HTML hides the actual contents from the email user.

It was once the mere malicious attachment one had to fear. “Don't open attachments that are scripts or small executable programs,” was the plea. Then problem crept into the actual body of the email, and users often don't have to do anything to put the evil plan into action.

There might be a single, unseen tracking pixel or web beacon that is talking back to the source email server saying, "Yes, Alice opened the email, so this is a legitimate email address we can spam in the future." Of course that same functionality is also a feature of paid business email services. We just don't consider them part of this problem.

Wired provided some details in a March article, but don't install any add-ons or extensions implementing a mitigation before finishing the article.

At some point, email addresses became masked in some MUAs with sender-assigned "smart names," so while an email address might be "[email protected]", the name displayed could be "Your Friendly CEO and Ultimate Authority." Verifying the source email address became difficult.

Even more disturbingly is that contemporary MUAs, including the ones listed above, sometimes allow scripts to run within emails by default. These scripts can do an array of malicious things to the desktop, and just by viewing the email, the scripts are activated. The same functionality which displays yet another dancing cat video could also be stealing your full contact list and launch an attack on the local network.

Those dancing cats are often remote images embedded in the emails, hiding a whole array of nasty attacks, besides notifying the email sender that the email address is qualified as a future spam recipient.

What's the easy solution?

Quite simple, we need to ween as many people off HTML email as possible.

A confused rage from marketing departments is turning into an avalanche as I write, but I can't fight that fight for you, and it might be better to just make the case and back away slowly. A malicious tool for compromising desktops via email also happen to be essential tools for marketing departments far and wide.

Who doesn’t love multi-functional tools?

One quick example code snippet should illustrate the point.

Most users opening this full email would see an array of colors and funky emojis. For text-based email, something like this will appear:

<html>

<head>

<meta http-equiv=Content-Type content="text/html; charset=utf-8">

<meta name=Generator content="Microsoft Word 15 (filtered)">

<style>

<!--

/* Font Definitions */

@font-face

{font-family:Wingdings;

panose-1:5 0 0 0 0 0 0 0 0 0;}

This email didn't contain any malicious scripts; it was mere unsoliticited commercial email, aka spam. The upside was that at least it was formatted with UTF-8, instead of some funky local character set.

More lines could be pasted here, but this 34.1KB email only had a few lines in the actual message. HTML formatting doesn't just obscure email contents, it also geometrically increases storage with no benefit for conveying basic messages.

Users of technical mailing lists should already be familar with ASCII-formatted email. Many mailing lists strongly emphasize the need for plain-text emails.

If a technical mailing list isn’t bothered by incoming HTML email, you might want to reconsider the merits of that technology.

At minimum, technical staff could likely do without HTML email. They generally don't need the bloated flashy version of email. They should be capable of using email without the dancing cat videos and other nonsense. They need email for the practical purposes related to their job, and probably already segment their personal email from work email. And if they have any track record in technology, they are probably familiar and might even have adopted the ASCII email campaign appearing in some email footers.

The technical staff are a prime target for phishing and all the email-based attacks so common due to their access privileges. They should at least be protected, if not everyone else.

The same goes for other frequently targeted parties. Journalists, human rights workers, high-profile targets, dissidents of whatever flavor: ASCII-only email should be the standard.

There are certain caveats to dwelling among the minority of ASCII-email users. Some MUAs only send attachments that are viewable to the recipient as HTML.

There's no need to move to the Unix shell for email access, using text-based MUAs such as mblaze or Mutt.

In Mozilla’s Thunderbird, forcing all displayed email to ASCII is as easy as setting “Message Body” in the menu to “Plain Text.” For more email formatting options, look at “Composition” in the Preferences, and select “Send Options.”

Outside of defaulting to text-based email sending and receiving, there's plenty of other security hacks to apply to Mozilla's Thunderbird to enhance safety. For instance, through the about:config interface, JavaScript can be disabled and remote images can be disallowed from loading in emails by default. Thunderbird is very customizable without diving into the swamp of extensions and add-ons.

Side note for more technical users: some useful hints can be siphoned from (the currently unmaintained) TorBirdy torbirdy.js file from the Tor Project. Those settings have direct correlation to about:config settings.

But turning off HTML email and just using ASCII text-based email is an easy security knob to turn.

Increasingly sophisticated attacks are here, and more are sure to come. One particularly malicious one is where an invoice is sent to the CFO or treasurer of some entity, allegedly from a more senior person in the same organization. An invoice is attached, routeable to some alleged vendor, with specific instructions for the finance person to pay it immediately.

That might be a basic AI-driven exercise, and also possible to accomplish with any language capable of processing web site scrapes.

It took us a while to get to this place where email became the gateway for so many data breaches and malicious attacks. The horse already left the barn, as the saying goes, and getting it back in is not a reasonable feat.

Displaying and sending email only as ASCII text isn't going to solve the world's email security problems, even if implemented everywhere overnight.

We can at least foster behaviors that enhance network asset protection, and those who can and are convinced, should start by bringing email back to its origins: a text-based interface to asynchronously communicate, and not the gallery of frivolous chatter that it's become.

Granted, locking down email MUAs will likely mean our Substack metrics will look worse, but hey, there’s always some tradeoff or another when it comes to security.

For those living as IT staff, in information security or with particularly privileged access to important data, just turn it off. The same goes for frequently targeted parties.

Forever green might be the tree of life, but just use your imagination instead of HTML to appreciate that tree over email.

George is a co-founder and CTO of ClearOPS. By trade, George is a systems administrator out of BSD Unix land, with long-time involvement in privacy-enhancing technologies. By nature, he thrives on creating unorthodox solutions to ordinary problems.

ClearOPS offers knowledge management for privacy and security ops data that is turned into information that can be used to respond to security questionnaires and conduct vendor monitoring. Do you know who your vendors are?