Subject: Doug attack scenarios without SPF

From: "William Leibzon" <[email-masked]>
Date: Fri, 10 Nov 2006 11:34:20 -0800

Hi,

While Doug has particular issue with SPF, the problem he points to has
little to do with SPF. In fact the attack is general dns attack that will
work with several other records (MX, SRV, NS, most likely PTR and NAPTR and
possibly CNAME [John Levine suggested it, but I don't immediately see using
it by itself]). The issue that certain applications (including DNS resolver
itself) by means of special DNS records can be directed to do several
additional lookups. The idea of the attack is to direct those lookups to
somebody else who would have to answer that it does not know about this
name. Those answers if original name is large can themselves be quite large
so you get amplification even though the answer i NXDOMAIN.

So specially for Doug I'm going to give example of using NS and EHLO for
this attack [note that my regular mail server and system with actual data is
currently down, so I'm trying to give an example from head; I tested this
yesterday], at the end I'll also explain why CSV is even better case for
launching this attack.

Lets assume that an attacker controls some domain
big.bad.domain.example.net  (for good amplification the name needs to be
pretty long; for better view in email I'm not doing it). He sends email with
SMTP session starting as
  EHLO big.bad.example.net
and he previously set up the following in DNS:
 $ORIGIN bad.example.net
   big IN NS victim-dns1.example.com
   big IN NS victim-dns2.example.com
   big IN NS victim-dns3.example.com
   big IN NS victim-dns4.example.com
   big IN NS victim-dns5.example.com
   big IN NS victim-dns6.example.com
   big IN NS victim-dns7.example.com
   big IN NS victim-dns8.example.com
If victim does not have enough dns servers, it can actually be done so as to
direct attack againt the same server - its more complex and I don't want to
go into it right now.

Now lets assume that as per Doug's scenario the email is sent using botnet
to many mail servers and we'll assume that those email servers are going to
try to resolve EHLO name (some would some would not - both CSV and SPF would
require it but many others do it anyway too). Now what happens is that each
mail server that received the email would try to resolve
big.bad.domain.example.net and as part of that would come to
bad.domain.example.net and would be by means of NS directed to victim DNS.
Victim servers would each answer that they are non-authoritive but would
have to include large domain (i.e. imagine big.bad.example.com being close
to maximum DNS label size) and that is where amplification comes from, i.e.
the attacker only responded with one packet which include
big.bad.example.com once in that packet and smaller size victim-dns (which
since NS supports label compression can be even smaller) where as the
response include that entire large name and comes from each and every NS
server listed. The above attack can be architect ed to be more then 10:1
with certain additional tricks.

Now I promised to explain why CSV makes it easy and is worse then SPF. That
is due to the suggestion of having to walk the dns tree which as far as I
remember it CSV specification has. Lets imagine that EHLO name is actually
bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do
lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above
system you cause multiple lookups due to lame delegation at
bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't
know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV
(as far as I understood it), the application would have to try
_client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup
lame delegation but this time at bad2.bad3.bad4.example.com zone.

And so this way you can easily cause many lookups for the same email session
from the same system  - that is why it is worse then with SPF. But in
reality if you look into it deeper, the actual amplification factor would be
the same as in all those cases you do one lookup for bad?.example.com and
cause to do 10x responses. It is exactly the same with SPF but in that case
Doug has used mx operator - he causes requests for MX hosted at attacker
side and several requests from victim for addresses pointed out but MX. This
all comes down to something like 10 amplification factor and not like 100 or
more like Doug says.

Again this is general issue that can be replicated using different DNS
records - its cause is that several DNS record types cause application (or
dns resolver) to do additional lookups to list of names specified in that
record [and SPF is not something new to this field, nor is it some type of
script like Doug says]. Another example of the same issue is when you send
email such that it would bounce (you can do it although now days email
systems are smarter) and you setup bad MX (like Doug did) which would cause
lookups to victim. It would be the same type of attack and amplification. I
can provide several more examples (email offers great choices since
anti-spam systems do a lot of lookups when trying to decide if its good or
bad email and if you use lots of domains for various victims like in URL
then you often cause some type of lookup to find if that name exists) as
well as examples in non-SMTP field (SNMP for example).

I hope this helped you all to understand it. Note that I'll probably not be
able to respond for a while (not only due to mail server problem which
should get fixed later today hopefully but largely because I'm still going
to in San Diego and expect not to spend my weekend connected to Internet and
answering emails).

William

---

From: John Leslie <[email-masked]>
Date: Fri, 10 Nov 2006 16:39:12 -0500

... clarifying one small portion...

> lame delegation but this time at bad2.bad3.bad4.example.com zone.

   This deserves some explanation.

   The CSV design team considered it important to have a way to specify
that any subdomains which send mail will have explicit CSV records. (Or,
more commonly, that _no_ subdomains should be sending mail.)

   It is quite specifically intended that the bit which specifies this
will be queried and cached by other  players than the receiving SMTP
server. Thus, you will find in section 7 of the CSA spec:
] 
] A receiving SMTP server MAY discover domain assertion information
] (after finding no record for the specific domain in the EHLO string)
] by searching for CSV-CSA records in parent nodes of the EHLO string,
] within the DNS hierarchy. Such a search MUST NOT query a top-level
] domain (such as COM, NET, or UK), and SHOULD NOT query deeper than a
] sixth-level domain.

   We quite clearly intended that implementors would provide a way to
disable these extra queries if they ever prove to be a problem.

   Speaking for myself only, I expected that reputation services would
perform these queries as new EHLO domains come to their attention and
periodically thereafter; and that their reputation reports would reflect
the domain owners' intent that subdomain EHLOs are not authorized.

   I was not able to get agreement of the design team to say this in
as many words in the spec. Nonetheless, the spec _is_ clear that any
reputation service would be entitled to do this.

   Thus, IMHO, it is likely that this feature would not be available
to be abused; and that at worst it might allow five extra queries.

--
John Leslie <[email-masked]>

---

From: "Markus Stumpf" <[email-masked]>
Date: Sun, 19 Nov 2006 03:40:48 +0100

Hoi,

On Fri, Nov 10, 2006 at 11:34:20AM -0800, William Leibzon wrote:
> to many mail servers [ ... ]

while I agree that there is some potential for a attack I don't see
it as a really big problem.
1) AFAIK no caching DNS server sends out to *all* servers in NS records
   immediately. Some are rather clever in detecting identical DNS servers.
2) Caching helps even against lame delegations (ok - the botnet may use
   random subdomains)
3) Neither for the sender nor for the receiver does it make a real
   difference how large the hostname in the query is as long as it fits
   in one UDP packet. It's a packet on the wire. Compared to web
   traffic hammering against busy webservers it is still peanuts.
4) It is easy for the MTA to check for the length of the EHLO argument
   and ensure that it fits in one UDP packet
5) It is easy for the MTA to immediately establish temp. blocks for IPs
   sending EHLO arguments that lead to errors
6) A lot of MTAs already now checks the domain of the 2821.MAILFROM so it
   is already now possible to start that kind of attack. This is nothing
   newly introduced.
7) LHS wildcard blocks for abusive domains will also fix the problem
   rather fast and can be automated. For the attack to work the attacker
   must own the SLD (or sometimes 3rdLD) to be able to introduce lame
   delegations. Also the DNS servers for those domains can be automatically
   isolated or blocked.

As I said - there is a potential for attacks but no new one.

	\Maex

---

From: Dean Anderson <[email-masked]>
Date: Mon, 20 Nov 2006 14:04:27 -0500 (EST)

> it as a really big problem.

I agree.

>    and ensure that it fits in one UDP packet

The SMTP server should not try to resolve the EHLO/HELO argument.  
There is nothing to learn from by resolving this argument.  It just adds
to the DNS load, and it increases the time to handle a signle message.
This then reduces the rate at which the mail server can process
messages, and increases the resources consumed by the email server.  
(gun-foot-fire-aim)

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Nov 2006 11:14:53 -0800

On Nov 18, 2006, at 6:40 PM, Markus Stumpf wrote:
>> Now lets assume that as per Doug's scenario the email is sent  
>> using botnet to many mail servers [ ... ]
>

When domains routinely process SPF scripts for accepted messages (not  
stopped by their block-lists), the potential impact of this operation  
might be extremely high. There would be little a victim could do to  
remedy the situation, which makes this a really big problem for them.

> 1) AFAIK no caching DNS server sends out to *all* servers in NS  
> records  immediately. Some are rather clever in detecting identical  
> DNS servers.

The NS record technique amplifies effects of an SPF script resolving  
addresses within 100 different domains executed for each email- 
address evaluated.  The evaluation process may occur for both the PRA  
and the Mail_From, for example.  This would then mean 200 domains  
times some number of errant and targeted DNSs contacted within a  
recursion process.  The spf-dos-exploit even excluded recursion  
overhead from the example attack gain calculations.  Without this  
overhead, the example SPF script generates 64 kbytes  of DNS traffic  
per execution!

> 2) Caching helps even against lame delegations (ok - the botnet may  
> use random subdomains)

This random domain selection is facilitated by the SPF script  
(without changing the script itself) as illustrated in the example  
attack.

> difference how large the hostname in the query is as long as it  
> fits in one UDP packet. It's a packet on the wire. Compared to web  

There is a big difference.  UDP does not provide congestion  
avoidance.  SPF routines abruptly timeout execution of a script,  
where a new script is then started.  The prior script may have  
encountered exponential back-off by DNS.   Running another script  
without waiting defeats congestion avoidance of DNS.  The problem  
described is an exploit made virtually free to attackers using a bot- 
net where complete flooding of a network backbone is made all too  
possible.

> 4) It is easy for the MTA to check for the length of the EHLO  
> argument and ensure that it fits in one UDP packet

An EHLO lookup would be for 1 host-name, and not the 10 host-names  
resolved within an SPF MX mechanism.  SPF also allows 10 MX  
mechanisms, which means SPF expects 100 times the number of DNS  
transactions (ignoring the transactions for the SPF TXT or RR 99  
records and that this might be done more than once per message).

> 5) It is easy for the MTA to immediately establish temp. blocks for  
> IPs  sending EHLO arguments that lead to errors

Exactly.  But the same is not true for SMTP clients offering SPF  
scripts resulting in passing or neutral results. : (

> 6) A lot of MTAs already now checks the domain of the 2821.MAILFROM  
> so it  is already now possible to start that kind of attack. This  
> is nothing newly introduced.

If there are MailFrom of the SMPT client checks made against a  
receiving MX record (which seems silly as this must be allowed to  
fail), then SPF would still increase the impact of this checking by  
an order of magnitude!

> 7) LHS wildcard blocks for abusive domains will also fix the  
> problem rather fast and can be automated. For the attack to work  
> the attacker must own the SLD (or sometimes 3rdLD) to be able to  
> introduce lame delegations. Also the DNS servers for those domains  
> can be automatically isolated or blocked.

No.  The victim can do nothing to prevent this attack, and there is  
nothing that those cooperating in the attack will notice.  The  
domains within the message can be completely different from the  
domains being attacked in the malicious SPF scripts.  It is rather  
common for bot-nets to use hundreds of throw-away domains each day  
(often at no cost to them).  Worse still the SPF results might be  
providing a PASS for all attacking messages referencing the malicious  
SPF scripts.

> As I said - there is a potential for attacks but no new one.

While a DNS based attack is not new, the level of obtained by this  
attack would be, and by a sizable amount.

-Doug