Subject: [Asrg] Problems that make the RMX proposal infeasible

From: "Jonathan Wilkins" <[email-masked]>
Date: Thu, 6 Mar 2003 12:02:34 -0800

I've been tracking this discussion for a little while and thought that
I'd finally de-lurk and give some comments.

I'm going to summarize some points that Adam Back has made and add
a little because it seems that some people have still not understood
the problems.  

Firstly, the DNS protocol is subject to spoofing.  This is a fundamental
problem with the protocol and cannot be fixed without totally changing
the protocol.  This is due to the fact that the first answer with a 
matching request ID is accepted.  Since the request ID is a 16 bit
field,
it is trivial for an attacker to send 65536 100 byte packets and provide
this answer.  

This is bad in general, but somewhat mitigated by the fact that it is
hard to determine when a given server will make a request and the fact
that most important things are backed up with SSL.  An attacker
may know that you bank with Wells Fargo, but will find it difficult to 
predict exactly when you're going to try and log into their servers.
Even if they manage that, you'll still be presented with a browser
warning
(or if they direct you to https://www.weelsfargo.com you stand a chance
of
noticing the unexpected URL)

In the context of the RMX proposal, neither of these are true.  The
attacker
knows roughly when you'll do the lookup. (Either when the MAIL FROM line
is
sent or when the message has been received.)  Furthermore, since the
attacker
gets to choose the TTL, the value of this attack is greatly increased.
Since the TTL is specified as an unsigned integer and given in seconds
this means that they only have to succeed with this attack once per
server.

Furthermore, since they don't care whether you're reading spam from 
[email-masked] or [email-masked], if they somehow fail the first
attempt, 
they can retry over and over again with varying domains.  As soon as
they
win once, they can spam for however long your DNS server actually caches
the record.

DNS IS NOT A VALID METHOD OF AUTHENTICATION!!!!!!!!

Note:
While it is possible to make this attack harder by varying the source
port too (which DJBDNS does and BIND doesn't) the total search space
is still too small to withstand a concerted attack.  This is made worse
by the birthday attack mentioned in the DNS Cache Poisoning - TNG paper)

Papers to read:
DNS Cache Poisoning - The Next Generation
The old problem of DNS cache poisoning has again reared its ugly head. 
While some would argue that the domain name system protocol is
inherently 
vulnerable to this style of attack due to the weakness of 16-bit 
transaction IDs, we cannot ignore the immediate threat while waiting for

something better to come along. There are new attacks, which make DNS 
cache poisoning trivial to execute against a large number of nameservers

running today. The purpose of this article is to shed light on these new

attacks and recommend ways to defend against them. 

http://www.securityfocus.com/guest/17905

--------
Mike Schiffman (aka route, past editor of phrack) has done an analysis 
of the current state of the world's DNS infrastructure.

Synopsis:
DNS servers across the Internet running BIND are not up to date with 
security patches and software updates. As a result, a significant
fraction 
of the Internet's DNS servers is vulnerable to compromise, subversion, 
denial of service, and general misuse. Considering that DNS is the
lynchpin 
of the corporate enterprise, the impact of these vulnerabilities is 
significant and a successful attack could bring down any online
business. 

http://www.packetfactory.net/DNS/

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Pierre BRUA <[email-masked]>
Date: Fri, 07 Mar 2003 13:09:27 +0100

> it is trivial for an attacker to send 65536 100 byte packets and provide

This scenario is unlikely to happen on a large scale :
1) This is more related to server hacking than spamming, which means 
spammers will risk a lot doing that.
2) That's a 6.5MBytes bandwidth consumption for each mail server you 
want to spoof. And you are not sure to succeed at first try (or even 
globally). Got to cost a little...
3) If spammers have to eat 6.5MByte of network bandwidth to send spam to 
a domain for a limited time (economically costly), and that only works 
with some DNS server software, I consider it's a sufficient protection.
4) You also need to know if dns requests are sent from the mail server 
or from other dns servers for this to work. My current configuration 
(for example) use a DNS server not from my ISP and located in another 
network...

Anyway, this has to be solved at the DNS protocol level, which clearly 
need to be improved on this subject as you mention it, and we will 
benefit from it when it gets solved globally.

I think defining a new secure DNS-like protocol for that would be too 
much of a headache. Let DNS people solve DNS problems.

Pierre
-- 
           PARALLINE          ///        Parallelism & GNU/Linux
                             ///
71,av des Vosges Phone:+33 388 141 740
F-67000 STRASBOURG Fax:+33 388 141 741 http://www.paralline.com
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg