Re: Doug attack scenarios without SPF

On Nov 18, 2006, at 6:40 PM, Markus Stumpf wrote:
> On Fri, Nov 10, 2006 at 11:34:20AM -0800, William Leibzon wrote:
>>
>> Now lets assume that as per Doug's scenario the email is sent  
>> using botnet 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.

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.

> 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.

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