[This email explains on scenario for what could be called 'NXDOMAIN'
DNS DoS which Doug tried to use in his FUD campaign against SPF
(I'll comment on that in next email). This is mostly same message
as I posted on MXCOMP (former MARID mail list) on Friday:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05839.html]
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 is 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 here 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 is NXDOMAIN or similar.
Specially for Doug I'm going to give example of using NS and EHLO for
this attack, at the end I'll also explain why CSV (Doug's alternative
to SPF) is even better case for launching such an attack.
Lets assume that an attacker controls domain big.bad.domain.example.net
(for good amplification the name needs to be pretty long; for better
view in email post 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.domain.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 against 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 mail servers & anti-spam filters do it
without that 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 servers. Victim servers would each answer
that they are non-authoritative but would have to include large domain
(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 names of victim dns servers (which since
NS supports label compression can be quite compact) where as the
response include that entire large name ('big.bad.example.com') and
comes from each and every NS server listed. The above attack can be
architected to be better then more typical 10:1 with certain additional
tricks and provided that email server and victim's dns servers are on
good network connection (most resolvers have no limit as to how many NS
they would check - they do usually have timeout though so how well it
would work would depend on network connection and timeout settings).
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 (up to
6 levels deep) which 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
that can be setup with "_client._smtp NS .." at zone
bad1.bad2.bad3.bad4.examp.e.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), 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. 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 servers do one lookup for bad?.example.com that cause to
happen 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
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
nowdays 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 and SIP both can be vulnerable to it to some degree).
I hope this helped you all to understand this attack scenarios.
--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
