Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Bill Cole]

On 15 Aug 2016, at 12:17, Tim Starr wrote:


I see your point, but why is it so bad to rewrite content links? I am
assuming a unique link per mailbox.


Change any content of a message and you invalidate any cryptographic 
signatures.


Rewrite links to go through your machines and you're effectively 
snooping on your users' correspondents and their clicking habits.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Brandon Long via mailop]

People assume click tracking, at the least.

It's not clear that it would help, anyways, the point of these attacks is
use them against another service, you might get some feedback but probably
not fast enough to matter, just like the per user dkim selector.

Brandon

On Aug 15, 2016 9:22 AM, "Tim Starr"  wrote:

> I see your point, but why is it so bad to rewrite content links? I am
> assuming a unique link per mailbox.
>
> -Tim
>
> On Sat, Aug 13, 2016 at 10:12 AM, Bill Cole  scconsult.com> wrote:
>
>> On 12 Aug 2016, at 19:12, Tim Starr wrote:
>>
>> The only benefit I can see from sending the exact same message from
>>> somewhere else would be to drive recipients to the same payload link,
>>> which
>>> suggests another possible way to stop this from paying off after
>>> detection:
>>> Make it so that all content links get turned into redirects you control,
>>> and can break upon request afterwards if needed.
>>>
>>
>> That works for a broadcast ESP but is a complete non-starter for a
>> mailbox provider like Fastmail. Screwing around with message content to
>> hijack links in nominally one-to-one email is just plain wrong.
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Tim Starr]

I see your point, but why is it so bad to rewrite content links? I am
assuming a unique link per mailbox.

-Tim

On Sat, Aug 13, 2016 at 10:12 AM, Bill Cole <
mailop-20160...@billmail.scconsult.com> wrote:

> On 12 Aug 2016, at 19:12, Tim Starr wrote:
>
> The only benefit I can see from sending the exact same message from
>> somewhere else would be to drive recipients to the same payload link,
>> which
>> suggests another possible way to stop this from paying off after
>> detection:
>> Make it so that all content links get turned into redirects you control,
>> and can break upon request afterwards if needed.
>>
>
> That works for a broadcast ESP but is a complete non-starter for a mailbox
> provider like Fastmail. Screwing around with message content to hijack
> links in nominally one-to-one email is just plain wrong.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vick Khera]

On Fri, Aug 12, 2016 at 7:12 PM, Tim Starr  wrote:
> The only benefit I can see from sending the exact same message from
> somewhere else would be to drive recipients to the same payload link, which
> suggests another possible way to stop this from paying off after detection:
> Make it so that all content links get turned into redirects you control, and
> can break upon request

You're not assuming the person doing the re-send is out for some form
of revenge to ruin the other person's reputation...

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Security Desk]

I'd think you could follow the links without rewriting them.

--
  Security Desk
  secure_m...@internet-mail.org



On Sat, Aug 13, 2016, at 10:52 AM, Brandon Long via mailop wrote:
> Doesn't it also make it harder to do spam detected unless you follow
> the links?
> Brandon
>
> On Aug 13, 2016 9:18 AM, "Bill Cole"  20160...@billmail.scconsult.com> wrote:
>> On 12 Aug 2016, at 19:12, Tim Starr wrote:
>>
>>
>>> The only benefit I can see from sending the exact same message from
>>>  somewhere else would be to drive recipients to the same payload
>>>  link, which
>>>  suggests another possible way to stop this from paying off after
>>>  detection:
>>>  Make it so that all content links get turned into redirects you
>>>  control,
>>>  and can break upon request afterwards if needed.
>>
>> That works for a broadcast ESP but is a complete non-starter for a
>> mailbox provider like Fastmail. Screwing around with message content
>> to hijack links in nominally one-to-one email is just plain wrong.
>>
>>  ___
>>  mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> _
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Brandon Long via mailop]

Doesn't it also make it harder to do spam detected unless you follow the
links?

Brandon

On Aug 13, 2016 9:18 AM, "Bill Cole" 
wrote:

> On 12 Aug 2016, at 19:12, Tim Starr wrote:
>
> The only benefit I can see from sending the exact same message from
>> somewhere else would be to drive recipients to the same payload link,
>> which
>> suggests another possible way to stop this from paying off after
>> detection:
>> Make it so that all content links get turned into redirects you control,
>> and can break upon request afterwards if needed.
>>
>
> That works for a broadcast ESP but is a complete non-starter for a mailbox
> provider like Fastmail. Screwing around with message content to hijack
> links in nominally one-to-one email is just plain wrong.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Bill Cole]

On 12 Aug 2016, at 19:12, Tim Starr wrote:


The only benefit I can see from sending the exact same message from
somewhere else would be to drive recipients to the same payload link, 
which
suggests another possible way to stop this from paying off after 
detection:
Make it so that all content links get turned into redirects you 
control,

and can break upon request afterwards if needed.


That works for a broadcast ESP but is a complete non-starter for a 
mailbox provider like Fastmail. Screwing around with message content to 
hijack links in nominally one-to-one email is just plain wrong.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[John Levine]

>If I understand what's going on, Y! is doing an OR on DKIM & SPF and in
>this case, your SPF record is bypassed by the DKIM pass. 

No, Y! only uses DKIM to decide where to send FBL reports.  This is a
feature.

As Steve said, the way to solve the problem is not to sign mail
written by random strangers with a domain whose reputation you care
about.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Tim Starr]

The only benefit I can see from sending the exact same message from
somewhere else would be to drive recipients to the same payload link, which
suggests another possible way to stop this from paying off after detection:
Make it so that all content links get turned into redirects you control,
and can break upon request afterwards if needed. That way, once you detect
the problem, you can selectively break the links in the message so that it
doesn't work anymore after it has been sent. We had this problem at one of
my prior ESPs, where they'd use our link-tracking to camouflage their links
so our domain would appear in their messages, not theirs, then they'd send
them from somewhere else. The content was illegal enough to qualify for
nuking-on-sight of the account by us, and when we nuked the account the
links stopped working, too.

-Tim

On Fri, Aug 12, 2016 at 1:58 PM, Steve Atkins  wrote:

>
> > On Aug 12, 2016, at 11:52 AM, Vick Khera  wrote:
> >
> > On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins 
> wrote:
> >> You're vouching for / accepting responsibility for every mail you sign.
> >> If your users are bad actors - as they are in this case - you're
> accepting
> >> responsibility for that.
> >
> > So if I took any random message that I came upon signed by you and
> > spammed the world with it, you take responsibility for that?
>
> I would take responsibility for the message, yes. It's a message I signed
> and sent. That doesn't change just because it was forwarded to you by
> someone else.
>
> The sole reason for DKIM to be based on a body signature is that there
> is very little benefit to a bad actor taking someone else's mail and
> resending
> it with identical content, and when it comes to spam our mitigation is
> primarily
> financial.
>
> For example, I receive mail from my bank. It's DKIM signed so I know it's
> mail from my bank. I can take a thousand copies and send them to other
> people, and they too will know it's mail from my bank. What I can't do is
> change the account number, or the message, or the links in the mail. Once
> I do that, it's no longer mail from my bank.
>
> This works pretty well until you allow malicious parties to inject their
> own content
> into mail that you take responsibility for by signing it with DKIM.
>
> On most levels there's no deception going on by fastmail or their
> customers.
> Fastmail vouched for the message, as it was sent by one of their users.
> They're
> still vouching for that identical message, even when it's sent from
> elsewhere.
>
> There's nothing particularly new here. It's all pretty well understood,
> and even
> discussed a little in the DKIM RFC. And there's not really anything to
> "fix" other
> than understanding that a DKIM signature just tells you it's a message
> sent by
> someone the domain owner trusts enough to sign their mail. If that domain
> is
> wellsfargo.com or paypal.com or whitehouse.gov that tells me one thing
> about the
> message. If the domain is yahoo.com, fastmail.com or gmail.com it tells me
> another.
>
> Cheers,
>   Steve
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Tim Starr]

What Steve said: Unique domains per account, or for different groups. We
had to do this for link-tracking domains: userid.example.com instead of
links.example.com for all accounts.

-Tim

On Fri, Aug 12, 2016 at 10:34 AM, Steve Atkins  wrote:

>
> > On Aug 11, 2016, at 5:42 PM, Robert Mueller  wrote:
> >
> > Hi mailop
> >
> > So it appears at the moment that we're experiencing a DKIM replay attack
> > against us. Basically some people are signing up a trial FastMail
> > account, sending a couple of emails to a gmail account (to get them DKIM
> > signed by us), and then copying the entire content of the email and
> > sending it from an AWS instance.
>
> [...]
>
> > 2. I bet a number of services out there are using the domains in DKIM
> > signed emails for reputation tracking. So this may be affecting the
> > reputation of our domains, even though we're not the genuine source of
> > the majority of the emails.
> >
> > Does anyone know if (2) is actually true, or what sites might be doing
> > to avoid this? I guess checking the uniqueness of b= value in each DKIM
> > signature to see if it's truly the same email just replayed over and
> > over is one way?
>
> (2) is absolutely true, it's what DKIM is for.
>
> You're vouching for / accepting responsibility for every mail you sign.
> If your users are bad actors - as they are in this case - you're accepting
> responsibility for that.
>
> >
> > That's an interesting thought actually, I wonder if seeing many emails
> > with the same b= value is an easy way to actually detect spam and/or a
> > replay attack?
> >
> > I can't see an easy way to stop this. It's impossible to block every
> > single sent spam email ever, and all it takes is one email sent and
> > signed by us to be able to be replicated as much as anyone wants.
> >
> > I know that this is a known problem with DKIM, just wondering if anyone
> > else has seen this and or dealt with it and has any idea if we should
> > even be worried about it at all?
>
> It's trashing your domain reputation exactly as though the mail came from
> your servers. It's something to be concerned about.
>
> Messing around with invalidating selectors won't help, as by the time you
> know that a user is doing this the damage is already done - and reputation
> is tied to the d= value.
>
> What headers are you signing? 90% of the things DKIM does are to try
> and mitigate replay. Signing the To and Cc means that they can't be
> replayed
> with other email addresses in those fields (which makes a replay attack
> less attractive) and signing message-id and date help a little too. Begin
> careful
> to double-sign where appropriate - as we talk about at
> https://wordtothewise.com/2014/05/dkim-injected-headers/ -
> can help with clever replay attacks, but not against crude "immediately
> duplicate a
> message a thousand times with identical headers and body".
>
> There are some other things you could do to mitigate, but they might be
> too intrusive into your business model - assigning different d= values for
> different customers or different classes of customer, for example. The
> problems
> are caused by you sharing a reputation between legitimate users of your
> system
> and others. If the illegitimate users are all, for example, on free trials
> or new signups
> there are several obvious things you can do to mitigate. If they're not it
> gets trickier
> and most of the "obvious" mitigants would likely be more harmful than just
> eating the domain reputation hit.
>
> Cheers,
>   Steve
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Seth Mattinen]

On 8/12/16 03:28, Robert Mueller wrote:



It's also easy for the spammer to test. Signup trial account, send to
gmail. No DKIM signature or wrong domain? Use a credit card to pay.
Still not working? Buy a stolen account on some black market. Still not
working due to message content? just tweak their message content and
keep trying until they get the DKIM signature they want.




True, but each of the steps raises the bar for effort a little bit more. 
Right now you have a situation where FM signed an email and said yep we 
vouch for this, even though the bar to get that signature was a ground 
level free trial account.


~Seth

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Steve Atkins]

> On Aug 12, 2016, at 11:52 AM, Vick Khera  wrote:
> 
> On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins  wrote:
>> You're vouching for / accepting responsibility for every mail you sign.
>> If your users are bad actors - as they are in this case - you're accepting
>> responsibility for that.
> 
> So if I took any random message that I came upon signed by you and
> spammed the world with it, you take responsibility for that?

I would take responsibility for the message, yes. It's a message I signed
and sent. That doesn't change just because it was forwarded to you by
someone else.

The sole reason for DKIM to be based on a body signature is that there
is very little benefit to a bad actor taking someone else's mail and resending
it with identical content, and when it comes to spam our mitigation is primarily
financial.

For example, I receive mail from my bank. It's DKIM signed so I know it's
mail from my bank. I can take a thousand copies and send them to other
people, and they too will know it's mail from my bank. What I can't do is
change the account number, or the message, or the links in the mail. Once
I do that, it's no longer mail from my bank.

This works pretty well until you allow malicious parties to inject their own 
content
into mail that you take responsibility for by signing it with DKIM.

On most levels there's no deception going on by fastmail or their customers.
Fastmail vouched for the message, as it was sent by one of their users. They're
still vouching for that identical message, even when it's sent from elsewhere.

There's nothing particularly new here. It's all pretty well understood, and even
discussed a little in the DKIM RFC. And there's not really anything to "fix" 
other
than understanding that a DKIM signature just tells you it's a message sent by
someone the domain owner trusts enough to sign their mail. If that domain is
wellsfargo.com or paypal.com or whitehouse.gov that tells me one thing about the
message. If the domain is yahoo.com, fastmail.com or gmail.com it tells me
another.

Cheers,
  Steve


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vick Khera]

On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins  wrote:
> You're vouching for / accepting responsibility for every mail you sign.
> If your users are bad actors - as they are in this case - you're accepting
> responsibility for that.

So if I took any random message that I came upon signed by you and
spammed the world with it, you take responsibility for that?

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Steve Atkins]

> On Aug 11, 2016, at 5:42 PM, Robert Mueller  wrote:
> 
> Hi mailop
> 
> So it appears at the moment that we're experiencing a DKIM replay attack
> against us. Basically some people are signing up a trial FastMail
> account, sending a couple of emails to a gmail account (to get them DKIM
> signed by us), and then copying the entire content of the email and
> sending it from an AWS instance.

[...]

> 2. I bet a number of services out there are using the domains in DKIM
> signed emails for reputation tracking. So this may be affecting the
> reputation of our domains, even though we're not the genuine source of
> the majority of the emails.
> 
> Does anyone know if (2) is actually true, or what sites might be doing
> to avoid this? I guess checking the uniqueness of b= value in each DKIM
> signature to see if it's truly the same email just replayed over and
> over is one way?

(2) is absolutely true, it's what DKIM is for.

You're vouching for / accepting responsibility for every mail you sign.
If your users are bad actors - as they are in this case - you're accepting
responsibility for that.

> 
> That's an interesting thought actually, I wonder if seeing many emails
> with the same b= value is an easy way to actually detect spam and/or a
> replay attack?
> 
> I can't see an easy way to stop this. It's impossible to block every
> single sent spam email ever, and all it takes is one email sent and
> signed by us to be able to be replicated as much as anyone wants.
> 
> I know that this is a known problem with DKIM, just wondering if anyone
> else has seen this and or dealt with it and has any idea if we should
> even be worried about it at all?

It's trashing your domain reputation exactly as though the mail came from
your servers. It's something to be concerned about.

Messing around with invalidating selectors won't help, as by the time you
know that a user is doing this the damage is already done - and reputation
is tied to the d= value.

What headers are you signing? 90% of the things DKIM does are to try
and mitigate replay. Signing the To and Cc means that they can't be replayed
with other email addresses in those fields (which makes a replay attack
less attractive) and signing message-id and date help a little too. Begin 
careful
to double-sign where appropriate - as we talk about at 
https://wordtothewise.com/2014/05/dkim-injected-headers/ -
can help with clever replay attacks, but not against crude "immediately 
duplicate a
message a thousand times with identical headers and body".

There are some other things you could do to mitigate, but they might be
too intrusive into your business model - assigning different d= values for
different customers or different classes of customer, for example. The problems
are caused by you sharing a reputation between legitimate users of your system
and others. If the illegitimate users are all, for example, on free trials or 
new signups
there are several obvious things you can do to mitigate. If they're not it gets 
trickier
and most of the "obvious" mitigants would likely be more harmful than just
eating the domain reputation hit.

Cheers,
  Steve
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vladimir Dubrovin via mailop]

Robert Mueller пишет:
>
>> 1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in
>> time.
>
> Assuming the receiving side looks at it. But you probably mean the x=
> tag anyway to set the expiry time, the RFC explicitly says though:
>
> INFORMATIVE NOTE: The "x=" tag is not intended as an anti- replay
> defense.
>
> Anyway, if you look at the Received headers I posted:
>
> Thu, 11 Aug 2016 09:25:57 -0400
> ...
> Thu, 11 Aug 2016 06:16:00 -0700 (PDT)
>
> So it took about 10 minutes from Receiving the email at gmail until
> the were sending it from AWS. Having an expiry time that's < 10
> minutes in the future from when a message is sent is pretty dangerous.
> All it takes is a small problem on the receiving side for an email to
> be delayed 10 minutes.
>
>> 2. Use per-user selectors with different keys (as it was advised) and
>> remove DKIM records if replay attack is detected or simply switch to
>> new selector if per-user keys are impossible.
>
> As I previously noted... the timeline between signup a new account,
> send one email, copy it and mass send via AWS instance could all be
> done in minutes, and then thrown away. By the time you revoke the
> selector, 1000's of emails have already been delivered. Sure it'll
> stop future reusing that particular account, but they can easily just
> move on to a new account already.
>
>> 3. Do not DKIM-sign messages and/or use different domains for trial
>> accounts. If you have antispam with score, you can set some limits to
>> sign / not sign messages with DKIM based on the score.
>
> At the moment it's trial accounts, but we also see plenty of accounts
> with stolen credit cards, or long term accounts that are stolen as
> well (probably due to password reuse). Determining which accounts to
> feed into a separate domain is non-trivial.
>
> It's also easy for the spammer to test. Signup trial account, send to
> gmail. No DKIM signature or wrong domain? Use a credit card to pay.
> Still not working? Buy a stolen account on some black market. Still
> not working due to message content? just tweak their message content
> and keep trying until they get the DKIM signature they want.
>

Yes, but it it's even more simple for spammer to e.g. send mail from
Gmail to Gmail to get Gmail's DKIM. The fact they didn't probably means
Yahoo already uses this as a spam signature. Multiple messages from AWS
with the same DKIM from the set of well-known domains with mismatched
"To:" is a quite good signature, because nobody expects forwarders on
AWS. So, I believe the problem is temporary and will be fixed by Yahoo
with routine spam filtering process.

> Rob Mueller
> r...@fastmail.fm 
>


-- 
Vladimir Dubrovin
@Mail.Ru
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Robert Mueller]

> Laura Atkins has some pretty cool ideas here:
> https://wordtothewise.com/2014/05/dkim-injected-headers/
> I'd be interested to see if including those headers twice in the
> signature works, so an altered or second instance of them would
> fail DKIM.

They didn't alter any of the headers or add any extra headers. There's
no need for the To header to match the SMTP RCPT TO envelope in any way.

> And have you had success including the t= and/or an aggressive x=
> (expire time) for free accounts?

If you look at the Received headers I posted:

Thu, 11 Aug 2016 09:25:57 -0400 ...
Thu, 11 Aug 2016 06:16:00 -0700 (PDT)

So it took about 10 minutes from Receiving the email at gmail until the
were sending it from AWS. Having an expiry time that's < 10 minutes in
the future from when a message is sent is pretty dangerous. All it
takes is a small problem on the receiving side for an email to be
delayed 10 minutes.

Rob Mueller
r...@fastmail.fm
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Robert Mueller]

>  1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in
> time.

Assuming the receiving side looks at it. But you probably mean the x=
tag anyway to set the expiry time, the RFC explicitly says though:

 INFORMATIVE NOTE: The "x=" tag is not intended as an anti-
 replay defense.

Anyway, if you look at the Received headers I posted:

Thu, 11 Aug 2016 09:25:57 -0400 ...
Thu, 11 Aug 2016 06:16:00 -0700 (PDT)

So it took about 10 minutes from Receiving the email at gmail until the
were sending it from AWS. Having an expiry time that's < 10 minutes in
the future from when a message is sent is pretty dangerous. All it
takes is a small problem on the receiving side for an email to be
delayed 10 minutes.

>  2. Use per-user selectors with different keys (as it was advised) and
> remove DKIM records if replay attack is detected or simply switch
> to new selector if per-user keys are impossible.

As I previously noted... the timeline between signup a new account, send
one email, copy it and mass send via AWS instance could all be done in
minutes, and then thrown away. By the time you revoke the selector,
1000's of emails have already been delivered. Sure it'll stop future
reusing that particular account, but they can easily just move on to a
new account already.

>  3. Do not DKIM-sign messages and/or use different domains for trial
> accounts. If you have antispam with score, you can set some limits
> to sign / not sign messages with DKIM based on the score.

At the moment it's trial accounts, but we also see plenty of accounts
with stolen credit cards, or long term accounts that are stolen as well
(probably due to password reuse). Determining which accounts to feed
into a separate domain is non-trivial.

It's also easy for the spammer to test. Signup trial account, send to
gmail. No DKIM signature or wrong domain? Use a credit card to pay.
Still not working? Buy a stolen account on some black market. Still not
working due to message content? just tweak their message content and
keep trying until they get the DKIM signature they want.

Rob Mueller
r...@fastmail.fm
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Anna Ward]

Laura Atkins has some pretty cool ideas here:
https://wordtothewise.com/2014/05/dkim-injected-headers/
I'd be interested to see if including those headers twice in the signature
works, so an altered or second instance of them would fail DKIM.

And have you had success including the t= and/or an aggressive x= (expire
time) for free accounts?

-- 
Anna Grace Ward

On Fri, Aug 12, 2016 at 2:42 AM, Robert Mueller  wrote:

> Hi mailop
>
> So it appears at the moment that we're experiencing a DKIM replay attack
> against us. Basically some people are signing up a trial FastMail
> account, sending a couple of emails to a gmail account (to get them DKIM
> signed by us), and then copying the entire content of the email and
> sending it from an AWS instance.
>
> Because Yahoo uses the DKIM signing domain for it's feedback loop
> reporting, we're receiving 100's -> 1000's of reports, even though none
> of them were actually sent from our servers.
>
> Here's what the cut in the Received headers looks like:
>
> Received: from towersevent.net (ec2-52-2-96-133.compute-1.amazonaws.com
> [52.2.96.133])
> by alph136.prodigy.net (8.14.4 IN nd2 TLS/8.14.4) with ESMTP id
> u7BDOa9x029274
> for <...@att.net>; Thu, 11 Aug 2016 09:25:57 -0400
> Received: from new1-smtp.messagingengine.com
> (new1-smtp.messagingengine.com. )
> by mx.google.com with ESMTPS id
> y13si203649qkb.155.2016.08.11.06.16.00
> for <...@gmail.com>
> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256
> bits=128/128);
> Thu, 11 Aug 2016 06:16:00 -0700 (PDT)
>
> The bottom Received header shows the jump from us to gmail, but the top
> Received header shows that basically they just copied the entire email
> content, and sent it from an AWS instance to a @att.net account.
>
> Obviously we're concerned about this because:
>
> 1. We only learned about this because yahoo uses DKIM domains for FBL
> reporting. If they used IP's, we'd never have known about this
> 2. I bet a number of services out there are using the domains in DKIM
> signed emails for reputation tracking. So this may be affecting the
> reputation of our domains, even though we're not the genuine source of
> the majority of the emails.
>
> Does anyone know if (2) is actually true, or what sites might be doing
> to avoid this? I guess checking the uniqueness of b= value in each DKIM
> signature to see if it's truly the same email just replayed over and
> over is one way?
>
> That's an interesting thought actually, I wonder if seeing many emails
> with the same b= value is an easy way to actually detect spam and/or a
> replay attack?
>
> I can't see an easy way to stop this. It's impossible to block every
> single sent spam email ever, and all it takes is one email sent and
> signed by us to be able to be replicated as much as anyone wants.
>
> I know that this is a known problem with DKIM, just wondering if anyone
> else has seen this and or dealt with it and has any idea if we should
> even be worried about it at all?
>
> --
> Rob Mueller
> r...@fastmail.fm
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vladimir Dubrovin via mailop]

There are few ways to mitigate attacks:

1. Add timestamp (t=) to DKIM-Signature. It limits replay attacks in time.
2. Use per-user selectors with different keys (as it was advised) and
remove DKIM records if replay attack is detected
or simply switch to new selector if per-user keys are impossible.
3. Do not DKIM-sign messages and/or use different domains for trial
accounts. If you have antispam with score, you can set some limits to
sign / not sign messages with DKIM based on the score.

Robert Mueller пишет:
> Hi mailop
>
> So it appears at the moment that we're experiencing a DKIM replay attack
> against us. Basically some people are signing up a trial FastMail
> account, sending a couple of emails to a gmail account (to get them DKIM
> signed by us), and then copying the entire content of the email and
> sending it from an AWS instance.
>
> Because Yahoo uses the DKIM signing domain for it's feedback loop
> reporting, we're receiving 100's -> 1000's of reports, even though none
> of them were actually sent from our servers.
>
> Here's what the cut in the Received headers looks like:
>
> Received: from towersevent.net (ec2-52-2-96-133.compute-1.amazonaws.com
> [52.2.96.133])
>   by alph136.prodigy.net (8.14.4 IN nd2 TLS/8.14.4) with ESMTP id
>   u7BDOa9x029274
>   for <...@att.net>; Thu, 11 Aug 2016 09:25:57 -0400
> Received: from new1-smtp.messagingengine.com
> (new1-smtp.messagingengine.com. )
> by mx.google.com with ESMTPS id
> y13si203649qkb.155.2016.08.11.06.16.00
> for <...@gmail.com>
> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256
> bits=128/128);
> Thu, 11 Aug 2016 06:16:00 -0700 (PDT)
>
> The bottom Received header shows the jump from us to gmail, but the top
> Received header shows that basically they just copied the entire email
> content, and sent it from an AWS instance to a @att.net account.
>
> Obviously we're concerned about this because:
>
> 1. We only learned about this because yahoo uses DKIM domains for FBL
> reporting. If they used IP's, we'd never have known about this
> 2. I bet a number of services out there are using the domains in DKIM
> signed emails for reputation tracking. So this may be affecting the
> reputation of our domains, even though we're not the genuine source of
> the majority of the emails.
>
> Does anyone know if (2) is actually true, or what sites might be doing
> to avoid this? I guess checking the uniqueness of b= value in each DKIM
> signature to see if it's truly the same email just replayed over and
> over is one way?
>
> That's an interesting thought actually, I wonder if seeing many emails
> with the same b= value is an easy way to actually detect spam and/or a
> replay attack?
>
> I can't see an easy way to stop this. It's impossible to block every
> single sent spam email ever, and all it takes is one email sent and
> signed by us to be able to be replicated as much as anyone wants.
>
> I know that this is a known problem with DKIM, just wondering if anyone
> else has seen this and or dealt with it and has any idea if we should
> even be worried about it at all?
>


-- 
Vladimir Dubrovin
@Mail.Ru
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Paul Smith]

On 12/08/2016 01:42, Robert Mueller wrote:

2. I bet a number of services out there are using the domains in DKIM
signed emails for reputation tracking. So this may be affecting the
reputation of our domains, even though we're not the genuine source of
the majority of the emails.


Hmm, looking at it from a different angle, isn't it RIGHT that your DKIM 
signature reputation is lowered slightly? Surely this is the price paid 
for not controlling whose emails you sign. If you don't control that, 
then the reputation of your domains SHOULD be lower than if you did.





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Eliot Lear]

If I understand what's going on, Y! is doing an OR on DKIM & SPF and in
this case, your SPF record is bypassed by the DKIM pass. 
The only thing to be done on your end is to not publish a DKIM record,
and then you're at risk for a prefix hijack, though that is visible to
some receivers, and it requires a bit more work to do.

I like your idea of the receiver logging b= and for that matter
message-id, and tossing messages that are not within a certain date
range (that way you can reduce those logs).

Eliot

On 8/12/16 2:42 AM, Robert Mueller wrote:
> Hi mailop
>
> So it appears at the moment that we're experiencing a DKIM replay attack
> against us. Basically some people are signing up a trial FastMail
> account, sending a couple of emails to a gmail account (to get them DKIM
> signed by us), and then copying the entire content of the email and
> sending it from an AWS instance.
>
> Because Yahoo uses the DKIM signing domain for it's feedback loop
> reporting, we're receiving 100's -> 1000's of reports, even though none
> of them were actually sent from our servers.
>
> Here's what the cut in the Received headers looks like:
>
> Received: from towersevent.net (ec2-52-2-96-133.compute-1.amazonaws.com
> [52.2.96.133])
>   by alph136.prodigy.net (8.14.4 IN nd2 TLS/8.14.4) with ESMTP id
>   u7BDOa9x029274
>   for <...@att.net>; Thu, 11 Aug 2016 09:25:57 -0400
> Received: from new1-smtp.messagingengine.com
> (new1-smtp.messagingengine.com. )
> by mx.google.com with ESMTPS id
> y13si203649qkb.155.2016.08.11.06.16.00
> for <...@gmail.com>
> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256
> bits=128/128);
> Thu, 11 Aug 2016 06:16:00 -0700 (PDT)
>
> The bottom Received header shows the jump from us to gmail, but the top
> Received header shows that basically they just copied the entire email
> content, and sent it from an AWS instance to a @att.net account.
>
> Obviously we're concerned about this because:
>
> 1. We only learned about this because yahoo uses DKIM domains for FBL
> reporting. If they used IP's, we'd never have known about this
> 2. I bet a number of services out there are using the domains in DKIM
> signed emails for reputation tracking. So this may be affecting the
> reputation of our domains, even though we're not the genuine source of
> the majority of the emails.
>
> Does anyone know if (2) is actually true, or what sites might be doing
> to avoid this? I guess checking the uniqueness of b= value in each DKIM
> signature to see if it's truly the same email just replayed over and
> over is one way?
>
> That's an interesting thought actually, I wonder if seeing many emails
> with the same b= value is an easy way to actually detect spam and/or a
> replay attack?
>
> I can't see an easy way to stop this. It's impossible to block every
> single sent spam email ever, and all it takes is one email sent and
> signed by us to be able to be replicated as much as anyone wants.
>
> I know that this is a known problem with DKIM, just wondering if anyone
> else has seen this and or dealt with it and has any idea if we should
> even be worried about it at all?
>




signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Robert Mueller]

> Use a different selector for each account holder, and then revoke
> selectors that are abused.

That's an interesting idea, but I'm not sure it'll be a big help.

The reality is that the timeline between signup a new account, send one
email, copy it and mass send via AWS instance could all be done in
minutes, and then thrown away. By the time you revoke the selector,
1000's of emails have already been delivered. Sure it'll stop future
reusing that particular account, but they can easily just move on to a
new account already...

-- 
Rob Mueller
r...@fastmail.fm

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[David Harris]

Hi Robert,

On Aug 11, 2016, at 7:42 PM, Robert Mueller  wrote:
> I can't see an easy way to stop this. It's impossible to block every
> single sent spam email ever, and all it takes is one email sent and
> signed by us to be able to be replicated as much as anyone wants.

I haven’t used this in practice, but here is a possible solution:

Use a different selector for each account holder, and then revoke selectors 
that are abused.

In your DNS setup something like:

*.users._domainkey.fastmail.fm TXT "private key here"

Then sign mail with a selector like "u1234.users" where 1234 is a unique user 
identifier. (All of these selectors will have the same private key.)
 
When you detect a DKIM replay attack from a user, for example user 3456, you 
can delete that selector and make the signature invalid by creating this DNS 
record to take precedence over the wildcard:

u3456.users._domainkey.fastmail.fm TXT ""

You’ll have to rotate out the abused selector to mitigate the existing attack.

I hope this helps.

David Harris


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop