About emails impersonating Path Network

Tue Feb 7 14:09:49 UTC 2023

On Mon, Feb 06, 2023 at 12:41:43PM -0800, Michael Thomas wrote:
> This seems like a perfect object lesson on why you should use DKIM and SPF
> and make sure the sending domain can set up a p=reject policy for DMARC.

But it's not.  DKIM and SPF are mostly useless against competently executed
email forgery -- and can even be exploited to make it worse.  Thanks to
a combination of increasingly bad user interfaces, user ignorance,
TLD proliferation, and the ill-advised conflation of identification with
authenticity, it's not currently possible to stop email forgery in any
meaningful sense of the word "stop".

Let me illustrate part -- *part*, only part because a full explanation
would take many pages -- of this problem by example.  There are many
variations on this theme, so after reading it you're tempted to say
"But":  don't.  Because for every one of those "buts" there's a counter,
and again, expounding those would take many pages.  Focus on the concept
here, not the precise details of the particular example I've chosen.

Let's suppose that example.net is the target of an impersonation campaign.
And let's suppose that I'm the attacker.  Thanks to ICANN and unchecked
registrar greed, I can now register example.lol or example.guide or
example.life or any of a thousand variations.  Thanks to unscrupulous
hosting operations who don't care who their customers are or what
they're doing and can't be bothered to perform even perfunctory due
diligence, I'll have no problem getting a web/mail host for example.lol.

I can then clone example.net's web site, modifying the URLs as appropriate.
I can also set up MX records, DKIM, SPF, etc. all of which are syntactically
and semantically correct for example.lol.  It shouldn't be too difficult
to figure out which email addresses are valid at example.net: I could
scrape their web site, or go through the NANOG or IETF or other mailing
lists, or scrape social media, or just write to them from a freemail account
somewhere and see what turns up.  I can replicate those at example.lol.

So what I have now is a web site and mail system that copies example.net
in every detail EXCEPT for the TLD.  And that matters little, (a) because
all-singing all-dancing email interfaces are increasingly getting dumber
and hiding the actual email addresses of correspondents and (b) even if
they expose it, e.g.:

	From: Some Person <some.person at example.lol>

nearly every user out there will not pick up on the TLD.  (If you think
"lol" is a bit too obvious, then go through the list.  There are plenty
of others that aren't.  Not that it matters much, because I could always
just namesquat on example-pro in the .net TLD or some other variation
on that theme, just like was done to Path Networks in this instance.
And nearly every user out there won't catch that either.)

And as the chef's kiss on this, an increasing number of email user
interfaces will check the DKIM record and dutifully mark messages
like this as "authentic" -- which, from the viewpoint of DKIM, they
absolutely are.  Users will see the green address bar or checkmark or
whatever signifies this, and their brains will turn off, and they'll
proceed on the assumption that such messages are authentic.

TL;DR: email anti-forgery technologies are useless wallpaper slapped
over an underlying set of serious problems that nobody has any interest
in fixing because they're highly profitable problems.  They've completely
failed to justify their cost/complexity and are readily exploited as part
of attacks.

---rsk