ietf-mxcomp
[Top] [All Lists]

DDoS attacks via SPF

2004-06-29 23:09:43



The subject of using SPF to create DDoS attacks is not new.  For
example, I raised this subject back in December on this thread:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200312/0393.html


A while back, I took a look at this subject in detail.  Sadly, I
failed to record all my numbers, so I'm going to have to recreate them
if I want to publish them. :-<


The conclusion I came to was:

The current SPF system is pretty resistant to DoS attacks, but I think
the SPF spec needs to have a lot more limits placed on the processing
in order to really prevent most abuse.  The goal doesn't need to be
that SPF can never be abused in any way, just that it is easier and
more useful to use other techniques to be abusive.  It's kind of like
it not being important that you can out-run a lion, just that you can
out-run the other people in your safari.


Most of the discussions so far have been about a spammer/cracker
attacking someone directly using a malicous SPF record.  That is, a
malicious SPF record is created, then email is sent to the victim's
MTA and the processing of the SPF record will cause problems for the
victim.  I think this is not a huge concern.  Reasonable limits can be
placed on the processing of SPF records and the victim can adapt when
this kind of attack is happening.


The much more serious problem, in my opinion, is using SPF to
indirectly attack someone.  A spammer/cracker could create a malicious
SPF record that causes DNS traffic to be directed to the victim when
email is sent to *other* MTAs.  This is the scenerio outlined in my
post from last December.  Evil.com creates a record that causes many
DNS lookups to be done against victim.com's name server.  Evil.com
then sends many SMTP commands that cause SPF checks to other MTAs and
each of those MTAs and *poof*, victim.com's bandwidth is gone.

With the indirect attack, the spammer/cracker is using other,
legitimate, MTAs to hide the source of the attack.  The victim can't
tell the IP addresses of the zombie machines being used, nor can the
victim even tell which domain is hosting the malicious SPF records.
The other MTAs that are being used may not be experiencing an unusual
load or traffic pattern and will probably do nothing to stop the
attack.

DNS caching actually helps the attacker.  The malicious SPF records
can have long TTLs.  The malicious SPF record can easily cause
NXDOMAIN results from the victim's name server, which rarely has a
long TTL.

The attacker doesn't need to send actual email, many systems will do
the SPF checks before the DATA command, so using SMTP pipelining, a
single TCP packet can contain many MAIL FROM/RCPT TO/RSET sequences.


Ok, after having all these evil ideas of how to abuse SPF, several
months ago I sat down and actually tried constructing them.  I found
that, in practice, it was a lot harder to make an effective attack
than I thought.  The amount of bandwidth consumed by the SMTP sessions
and DNS lookups on the spammer/crackers system is not going to be that
much less than the bandwidth generated by the SPF checks being sent to
the victim.  In particular, I had a hard time getting DNS requests
made via TCP to be cached, I found that bind had problems with name
compression on several of the more "interesting" malicious SPF
records, and in general, name servers consipired to make malicious SPF
records less useful. ;->


I hate doing handwaving here, but as I mentioned above, I can't find
my numbers from when I did these tests.


My conclusion is that the SPF spec *really* needs to have some tighter
processing specs added.  I sent patches to the spec of to Meng, but
they were not included in the most recent version.  Once the
processing limits get tightened up, I think SPF is in pretty good
shape, but more eyes checking this would be better.  (Again, thanks to
John Levine for doing real research.)


For those that want to see the malicous SPF records, dig around in
megamx.midwestcs.com, dos.midwestcs.com, dosredirect.midwestcs.com,
dosinc.midwestcs.com, and dosexists.midwestcs.com.



-wayne


<Prev in Thread] Current Thread [Next in Thread>