Bench Talk

So, let’s start our wee story here: Bob’s project is going well. Bob has diligently perused the Mouser Electronics website, gathered all the electronic provisions needed, created the first three iterations, and things look good. So good, in fact, Bob decides to go for some extra funding to give the project a little boost. Before long, the first prototypes will come off the line and Bob will be thinking about hiring people. Real people. Which will be a great comfort and help to the several robots he has now toiling over project details.

Production Note: Mouser Electronics has treasure troves of good stuff for all the reader’s robot needs.

This time, Bob heads straight to the bank. No time for an online funding website. After all, he doesn’t need much. Besides, a face-to-face meeting is satisfyingly old-school over applying for a loan on the bank’s website. The meeting with the loan officer is sublime. Funds will be granted!

Later, after the funds are safely squirreled away for the project’s next phase, Bob receives an email. It appears to be from the bank. The email looks perfectly authentic. It must be good. The bank, in the email, expresses concern and a sense of urgency. Click this link, the email says, to navigate to the website to fill in some details. Bob clicks the link. The link directs his browser to a site that looks exactly like his bank’s website. He doesn’t notice the URL of the site isn’t quite right. He signs in as usual.

Bob is now screwed. But he doesn’t know it yet. In a matter of hours, after visiting the bank’s website and signing in, Bob receives another email from… the bank. His bank. The real bank. It’s an automatic email notification telling Bob that his personal savings account, his project operating funds account, and his checking account have been withdrawn to the last penny. No questions asked. Because “Bob” withdrew the funds.

Of course, this sort of radical account activity spawns a phone call from a real person, one of the bank officials, to check on poor Bob. By then, it’s too late. And, more bad news. Alas, this bank has no real protection against being robbed straight out of the accounts. Or, at least, Bob didn’t sign-up for the protection. Have to be frugal, after all. There is The Project to consider. The bank official offers now-useless advice that the bank has been aware for awhile that there’s a scam going on and the bank is taking measures. The bank can’t do a thing about it other than send out warning emails, which no one reads, and perhaps even paper notices, which are not given a glance and are promptly recycled.

Safety Tip: The reader is encouraged to research and read the fine print on their bank’s fraud protections.

Later on, after much gnashing of teeth, wailing, and rending of clothes, it’s pretty easy to figure out. Bob realizes he got phished. The email wasn’t from his bank. The linked website wasn’t his bank’s website. Once he entered his login name and password, it was all over.

Phishing is one of the most primitive tech ways to rip someone off over the internets, across the webtubulars. It’s stunningly, embarrassingly low cost, low tech, the lowest-bar, and flat-out mind-blowing simplest of cyber skulduggery. It requires no firewall breakage, no sneakers, no spiffy cyber cannons and such whatnot.

What is phishing? In the simplest of terms, it’s deceptive email that looks authentic but is designed to trick the user. The trick depends on human behavior and lack of technical awareness. The user is said to be “phished” once they are tricked into being exploited, resulting in a successful attack.

Oftentimes, the user is tricked in clicking what appears to be a safe link, sending the user to an imitation website where the user enters in their login name and password. Clicking the link might instead install malware on the user’s computer with the user completely unaware anything happened. The trick doesn’t have to depend on clicking a link. It could be a malicious attachment which, once opened, does its dastardly deed. The range of badness possible with malware is breathtaking. Malware can recruit a user’s machine into a botnet for wicked purposes or could be ransomware that encrypts important files and holds them hostage until the user pays a fee.

Phishing relies on email that looks legit and the user believing the email is official and legitimate. The content of the email appears authentic and so does the sender address. The sender address will always be forged – the email will appear as sent from a trusted source but the email headers will reveal the origin is entirely different. This is called email spoofing.

Phishing happens all the time, everyday, sometimes with very public results and far-reaching consequences. For example, the notorious and sadly successful phishings in 2016 employed much sleight-of-hand, in the exploitation of the Gmail accounts of John Podesta and Colin Powell. Everyone involved became quite famous, more famous than they were already famous.

Among many of the tools from the phishing strategery toolbox, one of the most insidious phishing gambits is to send enterprise email within an institution from a hacked coworker’s email account, thus increasing the level of perceived trust. The email came from within the company or institution so it must be legit, right?

Lots of successful phishing attacks are never reported; ransoms are quietly paid, robbed bank accounts are unknown except to the financial institution and the customer. Again, human behavior. Being tricked and robbed via email shenanigans is something most would rather not admit and prefer to soon forget.

How easy is it to forge an official email? Fantastically easy, so easy that, given enough time, middle-schoolers, intelligent turtles, and robot stuffed toys could create spoofed, authentic-appearing corporate email. Okay, that last part was hyperbole but suffice to say, it’s easy. And there are all sorts of cheerful how-to articles out there.

Email content can be plain text. This is the safest email. What you see is literally what you have received. Just plain ol’ ASCII text, the lowest common denominator.

Email can also be sent as HTML to render in most email clients the same way browsers render web pages. HTML is HyperText Markup Language, the standard markup language for creating web goodness. Somewhere along the journey from the earliest days of websites and HTML and things of these natures, someone decided that email should look cool as web pages. Or cooler. Plain text is so boring. So, a way was devised to send the email in two sections: Plain text and HTML. Because, with some graphics and HTML and stylish CSS, email can look really snazzy, and really, really official, corporateish, bigly, and important. Just like using pld-fashioned company letterhead paper for official letters.

Except not. Anyone can duplicate the HTML to spin the exact same email. Some companies don’t even bother to send the plain text plus HTML combo, sending only HTML. Even easier, then. (Aside from the fact that HTML-only email simply is blank in email clients set to exclusively display plain text.)

As alluded to earlier, note that HTML-based email can also include CSS, that is, Cascading Style Sheets. And embedded graphics, or links to graphics, and other odds and ends. Just like a web page, HTML-based email can also embed scripting languages such as JavaScript. It’s hard to predict over the wide-range of email clients, versions, service packs, upgrades, bugs and bug fixes over the years if a script will run successfully but the security implications of executing code from inside an email are horrendous. Drive-by malware is achieved with an embedded script which runs the minute the email is opened. “Opened” also means “previewed” since email clients with the preview feature will open the email to preview it.

In Part II of this two-part series, we’ll take a look at how your basic HTML-based email is strung together, throw in more handy buzzwords, and offer some safety tips.

In the meantime, remember that friends don’t let friends do HTML-based email.