United States - Flag United States

Please confirm your currency selection:

Bench Talk for Design Engineers

Bench Talk

rss

Bench Talk for Design Engineers | The Official Blog of Mouser Electronics


Part II: Use HTML-based Email, Become Famous
On April 4, 2017 in All by Arden Henderson
Arden Henderson

 

In Part I, we described a scenario where Bob’s bank account was vacuumed to the last dollar after he was phished. We talked about phishing and various other nefarious email-related exploits, tricks, and landmines that slither around in the dark underbelly of the internets, splashing about in the webtubulars.

Let’s take a quick look at how your basic dubious HTML-based email is strung together. Here’s a stripped-down email with the usual suspects’ names changed and the company’s name spindled:


example/

Delivered-To: somedude@somewhere.com
Bunch of other headers here proclaiming Probably Not Spam, Etc.
From: somebody
To: somebody else
Subject: I am John's HTML-based Email
Date: Some date, in UTC if the sender is cool
Bunch of more headers not pertinent to the discussion
AND HERE IT IS:
Content-Type: multipart/alternative;
    boundary="_000_2BC30C31BEECA74B90F5A7DD4A388BCD367B3476TXEXMB01landmine_"
MIME-Version: 1.0
Return-Path: that somebody

--_000_2BC30C31BEECA74B90F5A7DD4A388BCD367B3476TXEXMB01landmine_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here is some text, explaining everything the reader needs to know.
Blah-blah. And Blah.

For more exciting info, hit our very important link

https://somescaryplace.com Super Very Cool Stuff Here!!

Thanks!

--_000_9040fe57fa334cada15dae09f056c706TXEXHUB01landmine_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"https://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"https://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--=0A=
/* Font Definitions */=0A=
@font-face=0A=
    {font-family:"Cambria Math";=0A=
    panose-1:2 4 5 3 5 4 6 3 2 4;}=0A=
@font-face=0A=
    {font-family:Calibri;=0A=
    panose-1:2 15 5 2 2 2 4 3 2 4;}=0A=
@font-face=0A=
    {font-family:Tahoma;=0A=
    panose-1:2 11 6 4 3 5 4 4 2 4;}=0A=
/* Style Definitions */=0A=
p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
    {margin:0in;=0A=
    margin-bottom:.0001pt;=0A=
    font-size:11.0pt;=0A=
    font-family:"Calibri",sans-serif;}=0A=
a:link, span.MsoHyperlink=0A=
    {mso-style-priority:99;=0A=
    color:#0563C1;=0A=
    text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
    {mso-style-priority:99;=0A=
    color:#954F72;=0A=
    text-decoration:underline;}=0A=
span.EmailStyle17=0A=
    {mso-style-type:personal-compose;=0A=
    font-family:"Tahoma",sans-serif;}=0A=
.MsoChpDefault=0A=
    {mso-style-type:export-only;=0A=
    font-family:"Calibri",sans-serif;}=0A=
@page WordSection1=0A=
    {size:8.5in 11.0in;=0A=
    margin:1.0in 1.0in 1.0in 1.0in;}=0A=
div.WordSection1=0A=
    {page:WordSection1;}=0A=
--></style>
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
ze:10.0pt;font-family:&quot;Tahoma&quot;,sans-serif"><br>
Here is some text, explaining everything the reader needs to know.
Blah-blah. And Blah.&nbsp;
<br>
For more exciting info, hit our very important link
<br>
<a href=3D"https://somescaryplace.com">Super Very Cool Stuff Here!!</a>
<br>
Thanks!<br>
<br>
<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_2BC30C31BEECA74B90F5A7DD4A388BCD367B3476TXEXMB01landmine--

/example

The multipart/alternative boundary makes it all clear. The top half of the email is mere plain text. The bottom half is HTML, wrapped around the actual message, plus heaping piles of additional HTML and embedded CSS, depending on how slick the email must be, usually dictated from on high. Company logo graphics, photos of happy people, product photos, and so on can be included in HTML-based email.

Multipurpose Internet Mail Extensions aka MIME makes it happen. This is the internet standard that injudiciously extended the format of email to be prettified, able to tumble through hoops, set computers on fire, and generally make a bad day if used for evil.

By the way, if the reader is wondering why all the “3D” text in the email source, the useful part is actually “=3D” and represents the ASCII equal sign. This is due to the quoted-printable encoding, one of the the two basic MIME content transfer encodings.

As a side comment, note that the reader can easily peruse email source since most, if not all, email clients have a “View Source” feature. Taking time to do this, especially with a supercharged, spruced-up HTML-based email, will be quite illuminating.

Okay, so back to the email source example above. The main thing to notice is the plain text version of the link clearly shows the actual link while the HTML version of the email will only display “Super Very Cool Stuff Here!!” as clickable text. The actual related link of sketchy purposes is hidden by the rendered HTML in the email client. This is because the HTML anchor element, which marks the beginning and end of a hyperlink, lets one define both the actual URL and a description, to wit:

example/

<a href=3D"https://somescaryplace.com">Super Very Cool Stuff Here!!</a>

/example

Notably, the anchor’s descriptive text, which becomes the clickable text, can be a graphic, a button, and most anything else. The point is the actual hyperlink is not visible in this context – it’s part of the HTML, the markup. In the same way, the links in this blog the reader is avidly reading just now are not visible, just the text associated with the link as defined by the code, that code being HTML. Email clients and web browers render pages based on the code; they don’t display the code. (Most email clients and browsers allow viewing the source code.)

Those who have chosen the paths of darkness, and toil away night and day on deplorable HTML-based email fashioned for squalid purposes, can, and do, create amazingly complex phishing email, complete with shortened URL links and other sly tricks such as steganography, surreptitiously concealing vicious computer-gobbling code inside photos of soft, cuddly bunnies and cosmically-cute kittens. Apparently, many of them are not aware their authoring software is generating plain-text/HTML email, exposing their dire schemes to those running plain-text-only email clients. If the unconscionable malcontents generate their egregious attacks as HTML-only email, then no harm done either – nothing shows up in plain-text-only emailers, therefore no link traps.

What to do? It’s easy: Set the email client to never display HTML-based email, only the plain text part, and to never compose and send HTML-based email. Yes, plain text email is simple but it’s also relentlessly straightforward and trustworthy.

Sure, even if the URL is visible and “is what it is,” it could be bogus. Slightly misspelled URLs are a time-dishonored way of tricking people to slimy sites which look impressively legit, for example, visually exactly the same as a trusted bank website. Nonetheless, at some point there must be competence and even just a vague awareness of how technical things work.

That is to say, at least with plain text email, one has a chance to discern the actual URL isn’t quite right. Not so with HTML-based email. (Unless the reader peruses the HTML-based email source each time, and, if that’s the case, no worries about the reader.)

A note of irony: HTML-based email does not render the same across all email clients, all machine configurations, all combinations of OS and application software, all hardware, all platforms. And it doesn’t always degrade graciously.

Take the font choice, for example. When creating the HTML-based email, the author makes a typographical design decision in choosing the preferred font plus some fallback fonts. If the font doesn’t exist on the user’s machine, HTML-based email rendering must degrade graciously, spiraling down through specified alternate fonts and finally some default font which will be different across the platform landscape. Already at that point, the rendered HTML does not look like the author intended.

The problems multiply. If the HTML-based email uses CSS3, it may be displayed in an email client that only is good to CSS2. If the HTML-based email is written as HTML5, rendering as intended goes out the window in older email clients unaware of HTML5.

Therefore, all that effort, time, and creative prowess to create a perfect, official corporate email is a roll of the dice out in the wild.

Sure, enterprise HTML-based email reliably renders the same inside the corporation because it’s a controlled environment with identical, or mostly identical, platforms. The corporate HTML-based email is beautiful and awesome and wonderfully represents the corporation… internally on identical company machines.

Yet, outside in the wind-blown flatlands of the email tundra, anything can happen. There is simply no predictability of how HTML-based email will render everywhere as compared to the authoring machine. In fact, given enough platform variations, HTML-based email will reliably degrade spectacularly in ways the author will never imagine. Certainly, care and effort to maintain fidelity to explicit corporate publication specifications will be squandered. Which, of course, completely renders pointless of doing bright and shiny HTML-based email in the first place.

In summary, we’ve touched on the disassembly of one malicious HTML-based email example masquerading as official email from a trusted institution, designed to exploit the user’s naivete and unawareness, directing the user to sign-in at a bogus site that appears authentic where the user’s password and login name will be gleefully captured.

But wait, there’s more. The reader may recall the related email nightmares mentioned in Part I of this series. Clicking a link in HTML-based email can cause malware to be installed straight into the user’s device. Merely opening email can run a script to download and install malware. Opening email attachments can silently deliver malware chaos. Cheerful email actually sent from trusted friends’ hacked email accounts, urging us to “click this link for more info about this exciting stuff I just discovered!” Hacked enterprise email accounts can result in highly trusted coworker internal email sent by exploited machines, packed full of unhappy surprises. Unencrypted can be intercepted and modified. And, unencrypted email – the bulk of email sent even today – is visible to crafty driftnets, the illusion of email privacy still somehow persisting after decades to the contrary.

User lack of awareness and the deceptive simplicity of email have been used for endless exploits for a long time now. The solution is technical awareness and alertness and common sense. Or switching to tin cans and string.

Once again, Dear Readers, remember that friends don’t let friends do HTML-based email.

Footnote: What about Bob? Readers will be happy to know that it turned out okay. Though his bank accounts had been vacuumed dry, Bob was able to turn to his trusted friend Alice for a goodly loan. The loan would make it possible to turn the electricity back on and get the robots charged and back to work. Alice wired the money a few hours ago, directly to Bob’s bank. Bob is waiting by his computer for the bank’s deposit confirmation notification.

It should show up any moment.



« Back


Arden Henderson spent at least part of his life toolsmithing in dark, steam-powered workshops of software tool forges long gone, drenched in blood, sweat, and code under the glare of cathode ray tubes, striving for the perfect line of self-modifying software and the holy grail of all things codecraft: The perfectly rendered pixel. These days, when not working on his 1964 Flux Blend time machine (which he inadvertently wrecked before it was built after a particularly deep recursive loop), Mr. Henderson works in part-time castle elf and groundskeeper jobs, chatting with singularities spawned from code gone mad in vast labyrinths of vacuum tubes, patch cords, and electro-mechanical relays. Mr. Henderson earned a B.S.C.S. late in life at Texas A&M. Over the hundreds of years gone by before then and after, he has worked in various realms ranging from petrochemical wonderlands spread across the flat Gulf Coast saltgrass plains, as far as the eye can see, to silicon bastions deep in the heart of Central Texas.

Related Posts

  • Part I: Use HTML-based Email, Become Famous

    Exploiting Doesn’t Have to be Complicated

  • Mouser’s STEAMy Summer: Part 1 of 3

    This STEAM-inspired three-article series will explore the available resources to assist you and your kids on a maker’s adventure and walk you through an embedded electronics project. We will cover the design, build, and code for the project as well as discuss how the data from the project can be useful to develop analytical and critical thinking skills.

  • “Think Like a Hacker” Part 1: Mindset, Kill Chain, and More

    Hackers approach their work much differently than engineers; rather than taking a systematic approach, they take a kill chain approach to exploit system vulnerabilities. What goes on inside a hacker’s mind is entertainment, chaos, and extreme volatility, so bring some coffee, and let’s delve inside.

  • The NXP Cup: A Partnership for Lasting Impact

    Each year, students build, program, and race their model cars in the NXP Cup, aiming for the fastest times and precise maneuvering. Rafik Mitry, Technical Marketing Engineer at Mouser Electronics EMEA, discusses Mouser’s involvement in the NXP Cup and how students can benefit from the competition.

  • Mouser’s STEAMy Summer: Part 2

    In part 1 of our STEAMy summer blog, we talked about the resources available for parents and kids to explore STEAM topics so that they can develop hands-on embedded electronics skills through project-based learning. Now in part 2, we will dive into designing and coding an UV monitor and alert buzzer.

  • Securing IoT and IIoT Environments, Part 3

    In parts 1 and 2, we looked at protecting the MCU, data, and physical access. In the final part of this series we will examine network security.
14032 Views
Tagged With: HTML, Web Security

Search

Categories

Featured Authors

All Authors

Show More Show More
View Blogs by Date

Archives