Re: [ietf-dkim] Mailsploit

[Murray S. Kucherawy]

On Tue, Dec 5, 2017 at 2:52 PM, Pawel Lesnikowski 
wrote:

>
> DKIM works as expected, but as you said it may re-enforce an incorrect
> assumption that email is from respected source.
>
>
Only if it's abused by saying "DKIM signature verified, it's safe!" rather
than " signed this, hope that's cool".

-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[Murray S. Kucherawy]

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 
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
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[Dave Crocker]

On 12/5/2017 1:44 PM, Steve Atkins 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).



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/

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

Re: [ietf-dkim] Mailsploit

[Grant Taylor]

On 12/05/2017 03:52 PM, Pawel Lesnikowski wrote:
encoded-words are simply not permitted inside email addresses. MUA 
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.


Attempting to decode is the first problem, incorrectly handling null 
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.

DKIM works as expected, but as you said it may re-enforce an incorrect 
assumption that email is from respected source.


:-/



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[Pawel Lesnikowski]

>
>
>> What is "naive" or "incorrect" about the following decoding?
>
> po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com
>
> "=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode to
> "po...@whitehouse.gov"
>

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


>
> 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 "po...@whitehouse.gov"?
>
>
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.


> 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.


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

Re: [ietf-dkim] Mailsploit

[Steve Atkins]

> On Dec 5, 2017, at 2:23 PM, Grant Taylor  wrote:
> 
> What's worse, no security, or bad / false security?

That's DMARC's motto.

Cheers,
  Steve


___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[Grant Taylor]

On 12/05/2017 02:24 PM, Pawel Lesnikowski wrote:
I'm not sure if you noticed but it seems many client are affected by 
'mailsploit':

https://www.mailsploit.com/index


$ReadingList++

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: 
po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com 


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

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

po...@whitehouse.govpo...@whitehouse.gov@mailsploit.com

"=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=" quite literally does decode 
to "po...@whitehouse.gov"


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 "po...@whitehouse.gov"?


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.


Of course encoded words are not allowed inside email addresses (address, 
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 po...@whitehouse.gov, 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[Steve Atkins]

> On Dec 5, 2017, at 1:36 PM, Dave Crocker  wrote:
> 
> On 12/5/2017 1:33 PM, Steve Atkins wrote:
>> It's a DMARC issue rather than a DKIM one.
> 
> 
> How is it a DMARC issue?

From: {spoo-that-expands-to bill...@paypal.com\0}@badpeople.ru will be 
delivered and (on some clients) have a recipient-visible 822.From that looks 
like "From: bill...@paypal.com" 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: bill...@paypal.com ", 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
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[John R. Levine]

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


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


Regards,
John Levine, jo...@iecc.com, 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

Re: [ietf-dkim] Mailsploit

[Dave Crocker]

On 12/5/2017 1:33 PM, Steve Atkins wrote:

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

Re: [ietf-dkim] Mailsploit

[Steve Atkins]

> On Dec 5, 2017, at 1:24 PM, Pawel Lesnikowski  
> wrote:
> 
> 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:
> po...@whitehouse.gov\0po...@whitehouse.gov@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?

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 po...@whitehouse.gov " 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

[ietf-dkim] Mailsploit

[Pawel Lesnikowski]

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:
po...@whitehouse.gov*\0*po...@whitehouse.gov@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