Doug attack scenarios without SPF

------=_Part_87700_4088226.1163187260966
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_87700_4088226.1163187260966
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br>
<br>
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. <br>
<br>
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.<br>
<br>
Lets assume that an attacker controls some domain&nbsp;
<a href="http://big.bad.domain.example.net">big.bad.domain.example.net</a>&nbsp; (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<br>
&nbsp; EHLO <a href="http://big.bad.example.net">big.bad.example.net</a><br>
and he previously set up the following in DNS:<br>
&nbsp;$ORIGIN <a href="http://bad.example.net">bad.example.net</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns1.example.com">victim-dns1.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns2.example.com">victim-dns2.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns3.example.com">victim-dns3.example.com</a><br>

&nbsp;&nbsp; big IN NS <a href="http://victim-dns4.example.com">victim-dns4.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns5.example.com">victim-dns5.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns6.example.com">victim-dns6.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns7.example.com">victim-dns7.example.com</a><br>
&nbsp;&nbsp; big IN NS <a href="http://victim-dns8.example.com">victim-dns8.example.com</a><br>
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. <br>
<br>
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 <a href="http://big.bad.domain.example.net">big.bad.domain.example.net</a> and as part of that would come to
<a href="http://bad.domain.example.net">bad.domain.example.net</a> 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 <a href="http://big.bad.example.com">big.bad.example.com</a>
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 <a href="http://big.bad.example.com">big.bad.example.com</a> 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.<br>
<br>
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 <a href="http://bad1.bad2.bad3.bad4.example.com">bad1.bad2.bad3.bad4.example.com</a>. 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
<a href="http://bad1.bad2.bad3.bad4.example.com">bad1.bad2.bad3.bad4.example.com</a> 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 <a href="http://bad2.bad3.bad4.example.com">bad2.bad3.bad4.example.com</a> zone.
<br>
<br>
And so this way you can easily cause many lookups for the same email
session from the same system&nbsp; - 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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
William<br>

------=_Part_87700_4088226.1163187260966--