Subject: Re: Trouble with Sender Authentication

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Nov 2006 13:10 -0500

On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis <[email-masked]> wrote:
>
>
>On Nov 7, 2006, at 6:10 PM, Scott Kitterman wrote:
>
>>
>> On Tuesday 07 November 2006 18:41, Douglas Otis wrote:
>>
>>> Obsoleting existing libraries and related scripts as needed due to  
>>> the DDoS potential.
>>
>> When you say the word script, do you mean SPF records (Please, this  
>> is meant to be a yes/no question, there's no need to write a  
>> dissertation that repeats the arguements made earlier in the  
>> thread.  I read those already.)?
>
>The concern is with libraries that execute scripts labeled as SPF 1  
>or 2 contained within DNS resource records.  A potential attack  
>utilizing just the access of these resources records has not been  
>described.

Is that a Yes?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 8 Nov 2006 11:36:19 -0800

On Nov 8, 2006, at 10:10 AM, Scott Kitterman wrote:
>>> When you say the word script, do you mean SPF records (Please,  
>>> this is meant to be a yes/no question, there's no need to write a  
>> The concern is with libraries that execute scripts labeled as SPF  
>> 1 or 2 contained within DNS resource records.  A potential attack  

This has been succinctly answered.  Record is _not_ synonymous with  
script.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 8 Nov 2006 23:30:47 -0500

On Wednesday 08 November 2006 14:36, Douglas Otis wrote:
> > On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis <dotis@mail-
> >
> > abuse.org> wrote:
OK, then I guess that's no.

Record != Script.  I see from the above that in your view libraries execute 
scripts, so SPF checking library != Script.  I'm not sure what is left.  

Rather that rehash your 'succinct' answer, please point me to the page and 
line number(s) of your draft that either is a script or describes what it is 
and I'll look it up there.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Nov 2006 10:58:54 -0800

> and I'll look it up there.

Page 11 would be a place to start.  Results vary depending upon the  
library used to execute this script and the starting parameters.  A  
script may invoke other records.  In this case, this script invokes  
10 MX mechanisms defined by a macro with follow-on transactions for  
address records that are perhaps limited by the script processing  
library.  Other scripts, such as in the case of paypal.com invokes 10  
other SPF TXT resource records.  The SPF script defines subsequent  
record transactions.  In this case, the %{l} macro is used to select  
an array of MX RR sets.  The script defines the record set, but in  
converse a record does not define the set comprising the script.   
Processing the script includes initial parameters not found in any  
SPF record as well.

It seems best not to confuse the term script with that of record.   
They are truly different elements.

cert-test.mail-abuse.org.  IN  TXT  "v=spf1
     mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d}
     mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d}
     mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d}
     mx:9.%{l}.%{d} ?all"

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Nov 2006 12:52:50 -0800 (PST)

On Thu, 9 Nov 2006, Douglas Otis wrote:

> to select an array of MX RR sets.  The script defines the record set, but in 
> converse a record does not define the set comprising the script.  Processing 
> the script includes initial parameters not found in any SPF record as well.

I've examined this issue over last few days. This all has nothing to
do with SPF but with DNS in general in which Doug's SPF use is just
an example of range of similar attacks. The underlying problem is
really that if spammers have large collection of zombies under their 
control they can either use them either directly to launch an attack
(and spam is form of DoS too!) or indirectly to get others to to do 
something simiar with some additinal level or amplification (about
1-20 depending on complexity of DNS scheme). They don't really need
SPF for that at all. I need to work more on the numbers and examples
and also unlke Doug I've an issue with just publicly saying how to do
all that - this would be just way too useful for bad guys.

> It seems best not to confuse the term script with that of record.  They are 
> truly different elements.
>

Could someone kindly point me to workable CSV library so that I could
provide Doug with an example of using CSV to generate highier amount
of amplificatin then his assertions about SPF?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Nov 2006 14:32:44 -0800

On Nov 9, 2006, at 12:52 PM, william(at)elan.net wrote:

>> to select an array of MX RR sets.  The script defines the record  
>> set, but in converse a record does not define the set comprising  
>> the script.  Processing the script includes initial parameters not  
>> found in any SPF record as well.
>
> I've examined this issue over last few days. This all has nothing  
> to do with SPF but with DNS in general in which Doug's SPF use is  
> just an example of range of similar attacks.

SPF script is able to target many DNS transactions per each  
distributed message.  The number of executions depends upon the  
number of names being resolved, recipients, and instances within the  
path where an evaluation is performed.

> The underlying problem is really that if spammers have large  
> collection of zombies under their control they can either use them  
> either directly to launch an attack (and spam is form of DoS too!)  
> or indirectly to get others to to do something similar with some  
> additional level or amplification (about 1-20 depending on  
> complexity of DNS scheme).

One execution of the SPF script can generate 64 kbytes of DNS traffic  
without consuming the resources of an attacker.  Few attack  
strategies offer a scenario that is totally free to the attacker who  
is also interested in sending spam. : (

> They don't really need SPF for that at all.

When ACL restrictions on DNS and BCP38 becomes common, SPF still  
defeats these protective strategies.  : (

> I need to work more on the numbers and examples and also unlike  
> Doug I've an issue with just publicly saying how to do all that -  
> this would be just way too useful for bad guys.

Providing details was done by request as there remained a lack of  
understanding of the concern.  Don't underestimate the sophistication  
of those creating the Bot-nets now responsible for the major portion  
of the current spam.  A DDoS attack only needs to be done for a brief  
period of time to enable yet other exploits.

> Could someone kindly point me to workable CSV library so that I  
> could provide Doug with an example of using CSV to generate higher  
> amount of amplification then his assertions about SPF?

An SMTP client is unique at each stage of delivery.  Validating SMTP  
clients requires one small DNS transaction using either A or CSV  
records.  While each recipient might perform this transaction, gain  
is less than 1.  SMTP client validation transactions can not be  
redirected to a victim and still offer validation as can SPF.  In  
addition, subsequent stages of delivery will not provide  
amplification as it will for SPF evaluations, which precludes gain  
related to multiple recipients.  Multiple recipient gain remains a  
concern for SPF.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Nov 2006 15:15:06 -0800 (PST)

Doug, I don't have time for long discussion. But I'm telling you that
SPF has nothing to do with it and I can use either of "MX", "SRV" or
"NS" to generate similar amplification scenarios as you've done with
SPF using the same method. In fact CSV (as far as I remember it) would 
cause highier amount of amplification then SPF when bad guy controls 
domain put in EHLO and decides to play special dns games with that name.
And in exactly the same way as you did it would generate 10:1 DNS traffic 
amplification (SPF scenarios are basicly 10:1 amplification after throwing 
away all the extras).

On Thu, 9 Nov 2006, Douglas Otis wrote:

>>> to select an array of MX RR sets.  The script defines the record set, but 
>>> in converse a record does not define the set comprising the script. 
>>> Processing the script includes initial parameters not found in any SPF 
>>> record as well.
>> 
>> I've examined this issue over last few days. This all has nothing to do 
>> with SPF but with DNS in general in which Doug's SPF use is just an 
>> example of range of similar attacks.
>
> SPF script is able to target many DNS transactions per each distributed 
> message.  The number of executions depends upon the number of names being 
> resolved, recipients, and instances within the path where an evaluation is 
> performed.
>
>> The underlying problem is really that if spammers have large collection of 
>> zombies under their control they can either use them either directly to 
>> launch an attack (and spam is form of DoS too!) or indirectly to get 
>> others to to do something similar with some additional level or 
>> amplification (about 1-20 depending on complexity of DNS scheme).
>
> without consuming the resources of an attacker.  Few attack strategies offer 
> a scenario that is totally free to the attacker who is also interested in 
> sending spam. : (
>
> When ACL restrictions on DNS and BCP38 becomes common, SPF still defeats 
> these protective strategies.  : (
>
>> I need to work more on the numbers and examples and also unlike Doug I've 
>> an issue with just publicly saying how to do all that - this would be just 
>> way too useful for bad guys.
>
> understanding of the concern.  Don't underestimate the sophistication of 
> those creating the Bot-nets now responsible for the major portion of the 
> current spam.  A DDoS attack only needs to be done for a brief period of 
> time to enable yet other exploits.
>
>>> It seems best not to confuse the term script with that of record.  They 
>>> are truly different elements.
>>> 
>> provide Doug with an example of using CSV to generate higher amount of 
>> amplification then his assertions about SPF?
>
> An SMTP client is unique at each stage of delivery.  Validating SMTP clients 
> requires one small DNS transaction using either A or CSV records.  While 
> each recipient might perform this transaction, gain is less than 1.  SMTP 
> client validation transactions can not be redirected to a victim and still 
> offer validation as can SPF.  In addition, subsequent stages of delivery 
> will not provide amplification as it will for SPF evaluations, which 
> precludes gain related to multiple recipients.  Multiple recipient gain 
> remains a concern for SPF.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 9 Nov 2006 16:11:45 -0800

On Nov 9, 2006, at 3:15 PM, william(at)elan.net wrote:

> Doug, I don't have time for long discussion. But I'm telling you  
> that SPF has nothing to do with it and I can use either of "MX",  
> "SRV" or "NS" to generate similar amplification scenarios as you've  
> done with SPF using the same method.

Multiples of 100s of crafted DNS transactions directed toward a  
victim by each message can not be compared against transactions  
needed to obtain an MX, SRV, or NS resource record.  The MX, SRV, or  
NS resource records provide access to a service prompted by the  
client and not an attacker.  SPF scripts allow an attacker to  
orchestrate hundreds of transactions at millions of recipients. The  
gain of this exploit is large and essentially free for an attacker  
also wanting to spam.  For what other exploit would is be true?

> In fact CSV (as far as I remember it) would cause highier amount of  
> amplification then SPF when bad guy controls domain put in EHLO and  
> decides to play special dns games with that name.

CSV specified that a single target be used.  When associated with  
DKIM per DOSP, an address literal or a single A record offers  
sufficient validation.  Validating the EHLO simply does not offer any  
gain; nor is this gain is not multiplied by subsequent stages or  
multiple recipients.  SPF script transaction amplification is not  
10:1 but more than 100:1.  The gain executing SPF script is  
multiplied by recipients and stages of delivery, such as MTAs and MUAs.

> And in exactly the same way as you did it would generate 10:1 DNS  
> traffic amplification (SPF scenarios are basicly 10:1 amplification  
> after throwing away all the extras).

Some SPF scenarios are much larger than 10:1.  SPF scripts can cause  
havoc by additional 10 or 11 TXT wildcard resource record  
transactions, but I'll leave that to your imagination.  Any SPF  
script exploit bypasses protections offered by DNS ACLs and BCP38. : (

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Nov 2006 16:57:18 -0800 (PST)

> CSV specified that a single target be used.  When associated with DKIM per 
> DOSP, an address literal or a single A record offers sufficient validation. 
> Validating the EHLO simply does not offer any gain; nor is this gain is not 
> multiplied by subsequent stages or multiple recipients.

I'll post tomorrow example of how to do exactly the same attack as Doug
discribed using different record type (and it would also bypass DNS ACLs
& BCP38), specially for Doug I'll use EHLO in that example although in
practice it does not matter (it does not even need to be email).

---
William Leibzon
Elan Networks
[email-masked]

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Nov 2006 21:45:16 -0500

william(at)elan.net <[email-masked]> wrote:
> of amplification than his assertions about SPF?

   http://www.mipassoc.org/csv/

   If you're looking for implementations, I can vouch for the ones at

http://www.mipassoc.org/csv/deploy/exim.txt

   and

http://www.mipassoc.org/csv/deploy/JLC.txt

--
John Leslie <[email-masked]>

---

From: John Levine <[email-masked]>
Date: 10 Nov 2006 05:24:08 -0000

>> could provide Doug with an example of using CSV to generate highier
>> amount of amplification than his assertions about SPF?

It'll be a challenge.  CSV is a single DNS query per message, so the
only things you get to use for amplification are delegation and
CNAMEs.

I do agree that the DNS threat from SPF is not qualitatively worse
than what we already put up with for CNAMEs.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Nov 2006 15:00:34 +0100

william(at)elan.net wrote:

> "NS" to generate similar amplification scenarios

Maybe add NAPTR to the mix.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 10 Nov 2006 08:58:33 -0800

On Nov 9, 2006, at 9:24 PM, John Levine wrote:

>>> could provide Doug with an example of using CSV to generate  
>>> highier amount of amplification than his assertions about SPF?
>
> It'll be a challenge.  CSV is a single DNS query per message, so  
> the only things you get to use for amplification are delegation and  
> CNAMEs.
>

Chaining CNAMEs does not offer the same distributed attack.  CNAME  
chaining uses resources of the attacker.  While CNAMEs can be a  
problem, they represent a threat than can be identified and handled  
by the affected party.  The SPF attack can not be identified and  
there is no defense possible.  I would call that a qualitative  
difference.

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Fri, 10 Nov 2006 12:07:59 -0500 (EST)

> than what we already put up with for CNAMEs.

Actually, the top candidates for DNS amplification abuse are large SPF
records, followed by large collections IN-ADDR records for a single IP,
as is the case for large virtual hosting sites.  Both practices are
advocated by anti-spammers.

I recently saw a ~4k byte SPF record, published by an anti-spam site.  
DNSSEC signed SPF records will probably break the 8K limit.

Thats about a 90 to 1 amplification factor.

You can get some amplification with any record type.  You can only get
the high amplification with certain types and certain practices.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000