Hi Nanog,
It looks like someone with an axe to grind against our company has decided to email every AS contact they could find on PeeringDB, impersonating us and sometimes spoofing our domains.
We're aware of the emails and are sorry for the inconvenience. We've since added SPF records to the domains we own but don't use (the perps have since name-squatted some new ones). We're also actively working with law enforcement on the matter.
Thanks
Konrad Zemek
CTO Path Network
AS396998
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.
Mike
Is widespread impact confirmed?
Unfortunate. Our ASN’s and location contacts in PDB have not received anything from Path. I looked in search engines (quickly) and see nothing negative re: your ASN. I found a reference as new to the platform at AMSIX 7/21 for AS 396998. Lack of mail security bits on most platforms are flagged or quarantined AFAIK. These are typically called “Joe Jobs”. I’d save the LEA path for more important things (credibility).
Warm regards,
-M<
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.:
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
I've found this article before and implemented it for domains that we own, but do not use for e-mail purposes. Protect domains that do not send email - GOV.UK
Might be worth checking it out.
Cheers,
Rafael
Your only option is to monitor the generic tld's atp and register them yourself. Clone attacks are real, impersonation has been around since centuries and yes, its an attack vector but only impacting your customers. There is a vector you can pursue, its action by lawsuit. Would you rather pay the registration of the domain or would you rather pay the retainer costs of lawyers ...
This is what the free web permits. Your only choice at this point is the retainer fee and intergovernmental practices.
PeeringDB may be able to implement different practices but I have a pretty good feeling they are at their wits end to void practices that impact its "yellow pages" service.
[ PDB product committee hat on ]
I’ll make sure this gets visibility with the PeeringDB product/ops committee and see if we can contribute here. If we can help make it harder I’m sure we would.
Warm regards,
-M<
Have a feeling this will result in a privacy policy thats implemented in customer controlled switch's which is against having a central directory for free lookup's. And feel ambiguous to the current policy in place. Yeah you can certainly identify abusers that are performing queries that go beyond normal expectations but can you identify those that are a little pretentious and trying to protect a single org ?
Id be willing to come onboard to assist but I fear in this area I may be limited to impact. I feel its worth my time simply for the cause it causes too many ppl considerable time to react to financially and company posture.
Best Regards
This is not a advertisement or for personal benefit. (DISCLAIMER). This is a hobby.
There has been a real failing on the UI side, but that not the fault of the authentication protocols. Thunderbird which is what I use is completely useless and silent on authentication. For others who implement some UI indications, some of them aren't very obvious and often tentative. There is a Usenix paper which researched email auth and part of it was on user visible feedback. The long and short is that it was useful, but not a silver bullet. A large part of the problem from my read of it is that it wasn't ubiquitous and standardized ala the Lock icon on browsers. It's easy to make fun of that, but it is clearly better than nothing. MUA vendors are always at liberty to bring their requirements for extensions for protocols or even new protocols if it would help the user experience by guiding how MUA's make the UI decisions on the advice of senders. It's pretty clear that they find this niche at best. That is a pity because some uniformity could make this a positive feedback loop and up the utility greatly.
FWIW, lookalike domains can and do happen with http too. Nothing unique about that to email.
Mike
Then the bad guys throw in the occasional Cyrillic, etc. character that looks like a Roman one and things get even more fun.
At least with spear-phishing attacks you can bound the problem detection investigation since you know what your own domain's legit names are. Beyond that, I have no idea if any of the mailbox providers are doing anything about lookalike attacks. Email at least has the advantage that it is in hands of a user's provider who could care. CA's I'm sure couldn't care less.
Mike