By J.M. Porup
Email spoofing is forging email so it looks like it came from someone it didn’t. I learned to spoof email in the fall of 1993 during my sophomore year at Northwestern. An upperclassman in my dorm showed me. At that time, we read our email by telnetting into the campus mainframe and then using elm, the precursor to Mutt.
“Look,” he said, “You just change the “From” header to whatever you like. Don’t–don’t–ever do this for real or we’ll both get in trouble.” I never did.
For several decades email spoofing was that easy, and only in recent years have security mitigations for this problem been tacked on as a late afterthought. Kludges like SPF, DKIM and DMARC make email spoofing harder than it used to be, but these band-aids are not universally applied and workarounds remain for scammers and spammers and phishers to spoof.
Worse, trying to backport security onto email confounds some of the smartest security minds of our generation, most of whom would prefer to throw email away and start again from scratch. Email is insecure by design, because all email users in the early 1970s were either academic researchers or military folk and thus considered trustworthy. Because email is so deeply entrenched in our lives, trying to root out and replace it with something secure by design is tilting at windmills.
Forgery is just so much easier on the cyber domain. Forging handwritten signatures is hard. Skilled criminals offered (and still offer) this service, but the barrier to entry is high, as is the risk of getting caught. A handwritten letter, or even a typewritten letter with a signature you recognize, is a strong signal that the message sent is authentic.
That level of trust does not translate into the digital realm, but our brains have yet to catch up. An email from a trusted email address receives the same level of trust in our brain as a handwritten letter from a loved one–but without warranting that trust.
Who wants to hack your trust? So many people.
“I, thy CEO, doth hereby request thee transfer the paltrey sum of USD $14 million to our new supplier of gizmos, whatchamacallits and thingumbobs. As a feudal gesture of good faith, I have made blood oath of payment before the Celestial Serpent consumes yonder fiery orb. Please, my good number cruncher, make it so.”
I jest, but spoofed emails like this one litter the graveyard of well-meaning company careerists trying to please their boss. A believable email from your CEO telling you to wire money internationally: For many accounts payable departments, this is not only a daily, but perhaps an hourly occurrence.
How on earth is the business world to keep turning if nothing in your inbox can be trusted? Well, we’re working on it.
SPF (Sender Policy Framework) was the first nascent attempt to cover a gaping wound with the smallest band-aid they sell. You know, those teensy tiny ones that are like an inch long and a quarter inch wide? That’s SPF.
First proposed in 2004, SPF didn’t become a Request for Comment (RFC) until 2014. SPF works by letting a domain admin publish which IP addresses are permitted to send email for that domain, thus making it possible for a receiving email server to check the DNS before accepting or rejecting any given email.
That teensy tiny band-aid turned out not to be enough, so a slightly thicker piece of gauze got applied: DKIM (DomainKeys Identified Mail), which cryptographically signs outgoing email on the server. Domain owners publish the public key in their Domain Name Service (DNS), permitting receiving email servers to look up and cryptographically verify DKIM signatures. DKIM didn’t become a standard until 2011.
What happens if an incoming email fails either or both the SPF and DKIM tests? Shrug emoji here. Enter DMARC (Domain-based Message Authentication, Reporting, and Conformance), a hacky kludge of a giant band-aid that mostly gets the job done, but that giant axe-gash still looks pretty gnarly. DMARC doesn’t really fix things, but gets the walking wounded email warriors back on their feet.
DMARC lets a domain owner publish in their DNS what they want to happen with spoofed email, and, crucially, it creates a reporting mechanism for receiving email servers to tell domain owners when they receive spoofed email. A typical deployment of DMARC starts at reporting only (“p=none”), then requests spoofed email be marked as spam (“p=quarantine”), and finally announces to the world that spoofed email should be bounced right back in the sender’s face (“p=reject”).
Despite all this good-faith work to secure email–and that has, it must be noted, significantly reduced email spoofing—smart attackers still have many technical loopholes to use.
Can’t spoof email from CEO@AcmeCorp.com because AcmeCorp.com has DMARC set to “p=reject”? Spoof an email from AcneCorp.com instead. The domain doesn’t have to exist. If it does, does that parked domain have DMARC applied? Maybe not.
Or heck, just create a throwaway Gmail account, CEOAcmeCorp@gmail.com. A careless reader, or someone in a hurry, might not think twice.
This assumes universal adoption–and correct configuration and deployment–of SPF, DKIM and DMARC, which is far from the reality we live in today.
Email spoofing is trivially easy, and the technical skills required to engage in this kind of attack are extremely low, and potentially hugely profitable. Until we figure out how to throw the entire email stack into the garbage and set in on fire and replace it with something secure by design, we’re going to be spending vast amounts of time and money defending our enterprises, our governments, and our society from this frustrating weakness.
This story, “Email spoofing explained: Who does it and how?” was originally published by
Got news? Contact me securely: https://github.com/toholdaquill/contact
Or for low security conversation: firstname.lastname@example.org
Copyright © 2020 IDG Communications, Inc.