Subject: [ietf-dkim] Mailsploit

From: Pawel Lesnikowski <[email-masked]>
Date: Tue, 5 Dec 2017 22:24:32 +0100

Hi All,

I'm not sure if you noticed but it seems many client are affected by
'mailsploit':
https://www.mailsploit.com/index

Basically the attacker uses special characters inside encoded words to
spoof the sender:

From:
=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@
mailsploit.com

Such header naively decoded incorrectly is:
[email-masked]*\[email-masked]@mailsploit.com

Although it's not a direct attack on DKIM, if DKIM is implemented properly
and email address decoding and displaying isn't, users might be fooled.

Of course encoded words are not allowed inside email addresses (address,
not names),
but is seems many clients try to decode them.

What are your thoughts?

-- 
Best regards,
Pawel Lesnikowski
https://www.limilabs.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Tue, 5 Dec 2017 13:33:14 -0800

> On Dec 5, 2017, at 1:24 PM, Pawel Lesnikowski <[email-masked]> wrote:
> 
> Hi All,
> 
> I'm not sure if you noticed but it seems many client are affected by 'mailsploit':
> Basically the attacker uses special characters inside encoded words to spoof the sender:
> 
> From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
> 
> [email-masked]\[email-masked]@mailsploit.com
> 
> Although it's not a direct attack on DKIM, if DKIM is implemented properly and email address decoding and displaying isn't, users might be fooled.
> 
> Of course encoded words are not allowed inside email addresses (address, not names), 

It's a DMARC issue rather than a DKIM one.

Most mobile clients and many desktop clients don't display the senders email address anyway, just the "friendly from" / human readable comment, so "From: POTUS [email-masked] <[email-masked]>" is much simpler and nearly as effective.

This[1] is a rendering bug the MUA authors really should fix, but not a terrible concern unless maybe you're looking at sneaky targeted phishing mail.

Cheers,
  Steve

[1] mailsploit, I mean. Maybe that other thing too.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Dec 2017 13:36:02 -0800

> It's a DMARC issue rather than a DKIM one.

How is it a DMARC issue?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 5 Dec 2017 16:38:25 -0500

> =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@

I'm with Steve, this is overclever in a world where most MUAs just show 
you the From: comment.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Tue, 5 Dec 2017 13:44:36 -0800

> On Dec 5, 2017, at 1:36 PM, Dave Crocker <[email-masked]> wrote:
> 

From: {spoo-that-expands-to [email-masked]\[email-masked] will be delivered and (on some clients) have a recipient-visible 822.From that looks like "From: [email-masked]" despite not having a valid DKIM signature with a d=paypal.com nor matching paypal.com's published SPF record.

That's DMARC working exactly as designed but not as commonly understood, which makes it a DMARC issue (though a usability one of unmet expectations rather than anything technical).

Much the same as "From: [email-masked] <[email-masked]>", or the various approaches that pad headers with various sorts of whitespace or v______e_____r_____y long local parts to hide the real domain part on mobile devices, etc.

Cheers,
  Steve

---

From: Grant Taylor <[email-masked]>
Date: Tue, 5 Dec 2017 15:23:14 -0700

> https://www.mailsploit.com/index

$ReadingList++

> =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com 
> <http://mailsploit.com>
> 
> [email-masked]<null>[email-masked]@mailsploit.com 

I'll show my ignorance.  (In the hopes to learn.)

What is "naive" or "incorrect" about the following decoding?

[email-masked]<null>[email-masked]@mailsploit.com

"=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode 
to "[email-masked]"

Or are you indicating that the naivety is the fact that MUAs may 
incorrectly handle the null containing string?  Possibly believing that 
the MUA will use null termination and incorrectly believe that the From: 
address is just "[email-masked]"?

> Although it's not a direct attack on DKIM, if DKIM is implemented 
> properly and email address decoding and displaying isn't, users might be 
> fooled.

That is an MUA issue.  Perhaps DKIM helps re-enforce an incorrect 
assumption based on a bad MUA trait.  But I don't see that as a DKIM issue.

> not names), but is seems many clients try to decode them.

Again, an MUA issue.  IMHO not a DKIM (or DMARC) issue.

> What are your thoughts?

I feel like this is a play on / adaptation of source routing (which is 
deprecated) in an attempt to make the MUA display a subset of the actual 
address in the from header.  (DMARC would also care about SPF's stance 
on the RFC821.From address.)

I feel like DKIM should 1) dutifully sign what comes in from the MSA.  I 
suspect that DKIM would use a domain (d=) of "mailsploit.com".  I 
further suspect that the RFC821.From address would also reflect 
"mailsploit.com".  Thus the message, seeming to be from "mailsploit.com" 
would pass SPF, DKIM, and likely DMARC.  This is because the message 
would really be from "mailsploit.com".

IMHO this really does boil down to MUAs behaving badly, thus enabling a 
bad belief that the message is from [email-masked], with SPF, 
DKIM, and DMARC supporting this bad supposition.

I really feel like this is an MUA issue.

What's worse, no security, or bad / false security?

-- 
Grant. . . .
unix || die

---

From: Steve Atkins <[email-masked]>
Date: Tue, 5 Dec 2017 14:37:54 -0800

> On Dec 5, 2017, at 2:23 PM, Grant Taylor <[email-masked]> wrote:
> 

That's DMARC's motto.

Cheers,
  Steve

---

From: Pawel Lesnikowski <[email-masked]>
Date: Tue, 5 Dec 2017 23:52:26 +0100

> "=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode to
> "[email-masked]"
>

encoded-words are simply not permitted inside email addresses. MUA
shouldn't attempt to decode this at all.

> incorrectly handle the null containing string?  Possibly believing that the
> MUA will use null termination and incorrectly believe that the From:
Attempting to decode is the first problem, incorrectly handling null
terminators and new lines is the second issue.
MUAs simply don't expect new lines and null terminators there.

> assumption based on a bad MUA trait.  But I don't see that as a DKIM issue.

DKIM works as expected, but as you said it may re-enforce an incorrect
assumption that email is from respected source.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Grant Taylor <[email-masked]>
Date: Tue, 5 Dec 2017 16:05:59 -0700

> shouldn't attempt to decode this at all.

Perhaps they shouldn't attempt to decode it per say.

I think they should attempt to detect the presence of invalid characters 
and act accordingly.

> terminators and new lines is the second issue.

Okay.

> MUAs simply don't expect new lines and null terminators there.

Isn't expecting something unexpected a tenant of security?

I.e. code defensively.

> assumption that email is from respected source.

:-/

-- 
Grant. . . .
unix || die

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Dec 2017 17:38:35 -0800

> That's DMARC working exactly as designed but not as commonly understood, which makes it a DMARC issue (though a usability one of unmet expectations rather than anything technical).

probably not.

it's an anti-abuse issue, where there is quite a bit of sloppiness and 
confusion about all of the relevant technologies.

but the problem and the issue is the broad need for much better clarity 
and precision than to assign a particular misunderstanding to that 
particular technology.  (People generally believe DKIM certifies the 
source of a message and even its authorship.)

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Dec 2017 17:52:59 -0800

I disagree that it's specifically a DMARC issue, because from that I infer
that you think DMARC is at fault here, i.e., that you expected it to deal
with this.

On Tue, Dec 5, 2017 at 1:44 PM, Steve Atkins <[email-masked]>
wrote:

> That's DMARC working exactly as designed but not as commonly understood,
> which makes it a DMARC issue (though a usability one of unmet expectations
> rather than anything technical).
>

Then it's also an email issue generally, because it's probably not commonly
understood that there doesn't have to be a relationship between the display
name and the email address, or between either of those and any other
identifier on the message.

This is just another display name attack.  The only thing that's
breathtaking this time is that some MUAs have evidently chosen to say it's
a server problem.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Dec 2017 17:54:07 -0800

> assumption that email is from respected source.
Only if it's abused by saying "DKIM signature verified, it's safe!" rather
than "<domain> signed this, hope that's cool".

-MSK