New Interesting Kind of Email Attack

General Privacy & Security
1

I’ve gotten a couple new intesting kind of spam/phishing the past few days in my librem.one email. (Names and numbers omitted below.)

Subject line reads: Voicemail Message (name >Tracy) from (nnn-nnn-nnnn)

Message text follows:>

You received a new message in your Librem Cloud Voice voicemail
box.

Date/Time of Call: 12/1/22 23:55PM EST
Calling Number: nnn-nnn-nnnn
Message Length: 8:22
Message Priority: normal
Voicemail Retrieval Number: Dail nnn-nnn-nnnn

IP OFFICE VOICEMAIL REDIRECTED MESSAGE.

Please Note: Deleting this email message does not delete the
voicemail message from your Librem Cloud voicemail box.

Take aways:

  1. I didn’t know librem.one had a voicemail service.
  2. If true and I let the messages accumulate I also presume the mail box will fill up.
  3. Message has an attachment with a clickable html payload.
  4. Also the message addresses are from me to me, so someone figured out to spoof my email and librem.one. (Although I didn’t check the source to see if there are hidden characters in the from address domain.)
  5. Noticed they couldn’t spell “Dial” correctly above.
  6. Interesting someone bothered to to spoof the librem.one domain.
  7. I haven’t had so much fun since my Nigerian prince.

P.S. No don’t give me advice on this. I’ve been trained. Just FYI.

2 Likes
2

Spoofing email is trivial:

  1. "From: " header is part of the message, not part of delivery coordinates, and is totally under control of the sender. Mail servers will not touch it - because they are not to interfere with mail data, but to faithfully deliver it.

  2. All mail clients in existence are stupid: They hide from users the SMTP envelope (in particular the SPF verified “envelope-from” field written by the receiving mail server) and trust the From: header to contain a trustworthy sender address.

1 Like
3

mutt might trust the From: header and thus qualify as stupid, but it does or easily can show the envelope-from header.

4

Yeah, text-based programs are superior in many respects, but they are not suitable for regular ordinary non-techie users - i.e. primary targets for mail spoofing. This is both ironic and sad, that GUI programs are trying so hard to be user friendly that they actually harm users.

I use Thunderbird. The way to see envelope-from is to look at “message source”. If I hadn’t grow up in a terminal land, if I hadn’t been sending my first emails by doing telnet 25, then I would notbe able to understand anything from that “message source”.

The difference betwen "From: " and envelope-from is this:

  • "From: " is under control of the sender, and the sender can put there whatever they want.
  • envelope-from is under the control of the receiving sever, and receiving server can (nowadays all of the do) verify the sender address using the sender IP and SPF DNS records and reject the mail if verification fails.
  • Spoofing origin IP or otherwise poisoning DNS (to defeat SPF) is orders of magnitude harder than writing arbitrary misleading things into "From: ".

For Thunderbird, the somewhat related feature request has been lying dormant since 19 years. But even that would only be a half of a solution. Even if a user could access Received-SPF header in an easy way, they would still need to know about it, and what to extract from that header.

5

So in other words, if using Thunderbird, use View / Message Source (available as CTRL-U) and see where the email was really from.

Basically, yes. The whole thing was designed in a kinder, gentler era of the internet.

A mail server is free to validate the From: header - and record additional information about the validity. That could feed into spam detection, for example.

But it’s slightly worse than you say …

because the envelope-from field is in principle not available to the end user at all. The receiving mail server is supposed to record it under the Return-Path: header but broken Microsoft sometimes sends a bogus Return-Path: header already - so either there will be two such headers, which is confusing for the user but semi-legitimate, or the receiving mail server needs to delete the original bogus (or malicious) Return-Path: header (which it is permitted to do). Worse still, the Microsoft gratuitous Return-Path: header, when present, is usually syntactically invalid.

Also, technically it is completely legitimate for the MAIL FROM / Return-Path to be different from the From:, even to the extent where they are in different domains. This is because the former is where bounces go but the latter is the default for where replies go. With the unfortunate rise of many commercial mail senders (legitimate, not spammers), it is common for the Return-Path: to be within the commercial sender’s domain while the From: reflects the actual sender (and is the only recognisable domain to the recipient).

The bounce address may even be a synthetic address that is unique for the destination, so that when a bounce occurs, it is easy to attribute the bounce to a specific destination and thereby potentially update the mailing list i.e. remove the failed destination or mark the destination as failed. I think this arises from the fact that there is no guaranteed way of associating a bounce with a destination.

Finally, the MAIL FROM can legitimately be an empty address ("<>"), thereby hampering validation attempts, by computer or human. Again, I think this arises from deficiencies in the way that bounces are handled.

More precisely … envelope-from is under the control of the sending server but the copy that is pre-pended to the email is under the control of the receiving server.

6

I’d be more receptive to this if the librem.one demarc policy wasn’t set to none thus not providing guidance to the receiving server on preferred action on failure…

Also dkim addresses the from vs mail from issue, so if properly implemented dkim+dmarc (along with the existing spf record) this particular spam should be effectively mitigated.

I’ve never understood why any mail service would set the dmarc policy to none, at minimum set it to quarantine. Also hopefully the reports are being parsed and acted on, though I don’t have high expectations based on my experience with other mail providers.

7

Ah control-U, it has been so long. I forgot.

So if anyone is interested here is the text up to but excluding the goofy chars for the attachment.

Blockquote
Return-Path: registro@lucasas.com
X-Original-To: tracy@librem.one
Delivered-To: tracy@librem.one
Received: from mx1.librem.one (mx1.librem.one [138.201.176.93])
by smtp.librem.one (Postfix) with ESMTPS id 7D9028355D
for tracy@librem.one; Fri, 2 Dec 2022 04:55:14 +0000 (UTC)
Authentication-Results: smtp.librem.one;
dkim=fail reason=“signature verification failed” (2048-bit key; unprotected) header.d=6meem.com header.i=@6meem.com header.b=“wX+TPzAq”;
dkim-atps=neutral
Received-SPF: Permerror (mailfrom) identity=mailfrom; client-ip=142.4.13.30; helo=server.uay.qgg.mybluehost.me; envelope-from=registro@lucasas.com; receiver=
Authentication-Results: name mx1.librem.one; dmarc=fail (p=none dis=none) header.from=librem.one
Authentication-Results: mx1.librem.one;
dkim=pass (2048-bit key; unprotected) header.d=6meem.com header.i=@6meem.com header.b=“wX+TPzAq”;
dkim-atps=neutral
Received: from server.uay.qgg.mybluehost.me (server.uay.qgg.mybluehost.me [142.4.13.30])
by mx1.librem.one (Postfix) with ESMTPS id B822A81E8E
for tracy@librem.one; Thu, 1 Dec 2022 20:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=6meem.com;
s=default; h=Content-Type:List-Unsubscribe:MIME-Version:Message-ID:Date:
Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=EKZYtKFGk9DnmVEAAiFIR9Wxdm5z3PpSJGQjIvEsOwc=; b=wX+TPzAqvq6W568wBSCdahRLlB
cr9dAOOCx0MoP3AT1vwEeYV5IrydsvH3TxAHEAcvmhbFUepaM/OI2S4mXQDK4TPovYpP5N0VS7RjL
G7t5oqNN7gCCwYRogUg2F7SqysOeqJ59NbJCuwfG1tpDpA56vQ2qXYQerWPzpkVZ/FMB56mXX3MkN
qvqyZV9IKnsHswpUQ1VOmsLgUKXrNMkVxdMkONxGmo5wG3/jh4BrqOaFclSWffILblsqimPBEFqZo
EQjT4bJWpQk8r6mrw2vL4qsEGPbze3LGSaAn3LvRkRFfIMr3frEqNiOoyU8wVN9XgRyid73LkqxOF
iFBnHqEQ==;
From: Librem Voice Mail tracy@librem.one
To: tracy@librem.one
Subject: Voicemail Message (Zelda Ada> Tracy ) From:(951-299-1537)
Date: 1 Dec 2022 23:55:03 -0500
Message-ID: 20221201235503.880C3687C0B34F25@librem.one
List-Unsubscribe: mailto:tracy@librem.one?subject=unsubscribe
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0012_8F70C433.E09431D5"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.uay.qgg.mybluehost.me
X-AntiAbuse: Original Domain - librem.one
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - lucasas.com
X-Get-Message-Sender-Via: server.uay.qgg.mybluehost.me: authenticated_id: info1@6meem.com
X-Authenticated-Sender: server.uay.qgg.mybluehost.me: info1@6meem.com
X-Source:
X-Source-Args:
X-Source-Dir:

This is a multi-part message in MIME format.

------=_NextPart_000_0012_8F70C433.E09431D5
Content-Type: text/plain;
charset=“utf-8”
Content-Transfer-Encoding: quoted-printable

Dear Tracy,

You received a new message in your Librem Cloud Voice voicemail=20
box.

Date/Time of Call: 12/1/22 23:55PM EST
Calling Number: 937-073-3103
Message Length: 8:22
Message Priority: normal
Voicemail Retrieval Number: Dail 312-490-1897

IP OFFICE VOICEMAIL REDIRECTED MESSAGE.=20

Please Note: Deleting this email message does not delete the=20
voicemail message from your Librem Cloud voicemail box.
------=_NextPart_000_0012_8F70C433.E09431D5
Content-Type: text/html; name=“MSG087435.html”; charset=“utf-8”
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=“MSG087435.html”

8

Yeah, dkim and dmarc show failed but it was delivered anyway because the policy is “none” instead of “quarantine” or “reject”. If the policy were at least “quarantine” then this should have landed in spam/junk/etc and if the policy were “reject” then this wouldn’t have ever been delivered to you.

The current configuration enables this kind of spam.

1 Like
9

Adding to that and echoing that … yeah, SPF shows failed but it would be delivered anyway because the SPF rule ends with “softfail”.

Specifically, it claimed MAIL FROM xxx@lucasas.com and the SPF rule for that domain is

v=spf1 +a +mx +ip4:198.57.247.205 +include:websitewelcome.com ~all

which would allow sending IP addresses of 192.254.234.204, 198.57.247.205 plus a whole (large) bunch of other IP addresses (probably designed to cause limits to be hit in some SPF implementations) … but not the actual sending IP address of 142.4.13.30

Therein lies the problem. It only takes one domain administrator in the world to set the SPF rule to end in a softfail (or neutral) and that domain can be abused by any spammer in the world.

However that actual SPF validation by librem.one failed with “Permerror”. I didn’t look into it to see whether that is caused by genuinely bad SPF data for the domain (lucasas.com) or implementation problems in Purism’s receiving mail server. This is also a trick used by spammers i.e. find implementation issues with SPF validation and then deliberately arrange SPF data that triggers those issues.

10

Thanks!

BTW, whose config? Mine or the librem.one folks?

If it is the librem.one folks, not my job then.

notmyjob
notmyjob490×686 170 KB

If it is me, maybe it is something I can change in that dratted infinitely long file I can never remember the name of in that hidden directory.

11

These problems are generally not within the control of the end user.

However it seems as if there is a DKIM Verifier add-on for Thunderbird, which you could try. I don’t use it so can’t say whether it works well.

I’m not really across the fine details of DKIM but it looks to me that DKIM passed when checked by mx1.librem.one but failed when checked by smtp.librem.one so it may be that a DKIM Verifier would report success anyway (for this particular email).

1 Like
12

It’s not your problem to fix, this is on the mail providers not the end user.

However it is your problem in that you are the one affected not the provider. The only real actions open to you are, reach out to librem.one support so they know one of their customers is being affected, and go through the headers to report abuse to the hosting provider of the sending server as well as the domain being impersonated (lucasas.com) and maybe even report to their dns registrar. Though most of those reports are likely to be ignored since none of those entities are directly affected.

13

Next time it happens then. Too much entertainment on this one.

(Having retired from the support side, I know it helps if an incident is a few hours or minutes old instead of a serveral days like this one. I can just imagine the support guy having to search/scroll through logs with my error string.)

1 Like
14

In the case of email, if everything is configured properly, it should only be a couple of minutes (1-5) for the support person to find this exact email and it’s associated headers, the path it took, etc.

I’m just saying I would still report it.

15

OK, as long as they don’t say “Why did you take so long to report it?”

16

If they do I, and I’m sure others, would be very interested in learning that. Would be a huge disappointment, I’m hoping they wouldn’t do that.

17

That’s not 100% true. A bounce could go to the impersonated domain (in this case lucasas.com) and if repeated at scale, that might be annoying enough for them to tighten up their SPF record. In the early days of spam, this (bounce messages) was a major problem with impersonation. Nowadays I think more spam is dropped silently, which causes its own problems but does solve the problem of the impersonated party getting inundated with bounce messages.