Possible Denial Of Service using DNS

[cveira () AIRTEL NET (Carlos Veira)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I must admit that I have been really surprised seeing people's
'reaction'
on this particular matter. We are used to see really good debates when
something 'c00l' comes up to the scene... But this time, nothing: no
code review, no debate about possible solutions, ... :?.

FuSyS & sacco's message, was very interesting indeed. I, honestly,
don't
know if this has been known for a long time, despite its simplicity...
But what really matters is that this is a very hard to close gate...

Looking at the code i realized it was not very useful for auditing
purposes, so I decided to add some functionality and fix some
implementation problems which made the source compile but failing to
work nicely.

I. Description:
===============

This is a quick list of what has been added/modified to the original
code:

 1. Ability of managing a variable and different number of name
servers
    and querys.
 2. Ability of taking input data from text files.
 3. Added some fixes to the flood engine.
 4. Ability of controlling the times to be executed.
 5. Added some 'paralell processing' features.

There still remain some things to be improved, but they are far long
from
my original aims when I started this work. I might suggest the
following
enhancements:

It's somehow necessary to add some simple memory management. The
current
version works with a buffer which can manage MAX_SEVERS entries. There
are no memory management at all. That means that, when reading a file,
only the first MAX_SERVERS are considered. If we want to extend this
to
larger files this is to be added.

Another improvement would be to enhance the hash function in order to
get a
more uniform statistic distribution. This would carry out a better
'paralell' performance.

This 'paralell' feature trys to query different name servers with
different
questions at the same time. Such a thing would avoid some lame filters
and
make the attack more distributable among the whole DNS servers.

To work out this feature, the flooder begins in a different point
depending
on its PID. Given this situation, one can fork diferent processes from
de
command line and each of them will perform a different action in a
certain
moment. Of course more complex and efficient solutions could be worked
out,
but, once again, they are far long from my initial aims.

As it can be watched, such attack can be as powerful (or even better)
as
smurf or fraggle. Think this is more flexible and owns a grater degree
of
distribution. Let's put some evil imagination in motion... ;P

II. Impact:
===========

First of all, some notes:

  1. We are talking about UDP traffic. That means that there's no
     connection.
  2. We also must consider that the victim will recive packets with
     different
     sources (IPs and ports).
  3. We must remember that DNS is a critical service in the Internet:
     almost every service depend on it in a different degree.
  4. DNS can be reached from any place on the Internet: there is no
     restriction.

Let's consider a couple of scenarios. If the target is not shielded by
a
firewall, the effect of this attack is obvious: the host is flooded to
dead. So, what happend in a filtered environment? If the firewall uses
content inspection techniques, should drop all this traffic (these are
valid answers but no query has been performed on the protected
network).

In this case, the affected host will be the firewall. This is even
more
worrying than the first case because firewalls are esential devices on
network conectivity. If the firewall fails, all the network fails
(from
a conectivity point of view, of course).

We must remember that a firewall is more vulnerable to this kind of
overloads. To the *physical* traffic flooding itself, we have to add
the following :

  a. A firewall must perform a rule check for each I/O traffic. That
means
     some load.
  b. The logging process on the firewall means added load, mainly I/O
load
     through disk.

An encreasing number of DNS servers means a proportional raise on the
distribution degree this attack has. So, to bring a big firewall to
its
knees we only need to take a grate list of DNS servers.

The obvious side effect of such situation is a traffic overload on the
network segments on the way to the target. Using network switches
would
help to limit this annoying side effect.

III. Possible solutions:
========================

a.  Source IP filtering & Bandwith control:
    ---------------------------------------

    a.1 Source IP filtering:

    This may be one the most effective measures. By giving this type
of
    rule to routers, we *limit* the IP spoofing possibilities: such
rule
    would only allow traffic to pass over a network interface if the
    source IP belongs to a valid range on that interface.

    a.2 Bandwith control:

    Giving an I/O rate to DNS traffic could *help* too. This would
stop a
    flood based on a few DNS servers been queried intensively.
    Nevertheless, it is not very useful to the target network when
hitted
    by a highly distributed DNS flood. The reasons are the same ones
given
    in the case of the firewall. In this case the damaged system would
be
    the router itself.

    a.3 Problems:

    Source IP filtering it's great but it needs to be implemented on
every
    routing device on the Internet. If there's a place wich allows IP
    spoofing, the risk remains there.

    Unfortunately, IP filtering could not be necessary on some cases.
Let's
    see: besides the flooding effect, we get a global network
overload. If
    we also consider that today it's pretty common having more than
one PPP
    Internet access... So, we've got it...

    So it seems easy to log into an ISP perform the attack using a
valid
    ISP IP as the source, then disconnect and log in again with other
ISP
    while the other is being nuked by thousands of DNS servers on the
    Internet...

    The success on the choice of the valid ISP IP address depends on
the
    ISP network architecture and its *internal* filters.

b. DNS over TCP:
   -------------

   This may be *THE* solution. TCP architecture would make
'impossible' to
   achieve a successful query to a DNS server. Let's see:

      1. A connection is to be completed in order to perform a query.
      2. There exists connection control.

   On the 'best' case the target would be SYN+ACK flooded by thousands
of
   name servers on the Internet. But now we are not *amplifying* the
   traffic because no query response is given at all.

   But, is this a real possibility? Well reading the RFCs, the answer
is
   "YES, BUT...". Let's see:

   * RFC1034 ("DOMAIN NAMES - CONCEPTS AND FACILITIES") says:

     "In the Internet, queries are carried in UDP datagrams or over
      TCP connections."

   * RFC1035 ("DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION") says:

     "The DNS assumes that messages will be transmitted as datagrams
or in
      a byte stream carried by a virtual circuit.  While virtual
circuits
      can be used for any DNS activity, datagrams are preferred for
queries
      due to their lower overhead and better performance.  Zone
refresh
      activities must use virtual circuits because of the need for
reliable
      transfer."

   So it seems that DNS querys can use TCP. BUT what we need is the
server
   FORCING the use of TCP. It *seems* we could force this by editing
the
    file "/etc/services" and commenting or deleting the UDP entry:

   whois           43/tcp          nicname         # usually to
sri-nic
   domain          53/tcp
>  #domain          53/udp
   mtp             57/tcp                          # deprecated

   This way, both the *local* name server and *local* resolver would
use
   TCP on its domain name related tasks... This means that *local*
querys
   would work over TCP.

   The problem comes up, when an standard remote client querys a
   'TCP-forced' system. What happens when such a client starts an UDP
   query to a TCP service? Is it able to detect it and restart the
process
   using TCP?

   Unfortunately, I could not found any kind of information on this
matter.
   It seems to me that this is an unspecified case. It seems that UDP
& TCP
   are treated as separete worlds... I think that, in the best case,
this
   will depend on vendor implementation, and not as an standard
behaviour.

   b.1 Problems:

   Carrying DNS completely over TCP has serious load and performance
   problems. They are important enough to consider them with the
suitable
   calm.

   Besides that, we have de UDP/TCP interoperation problem mentioned
   before. This would imply reconfiguring or patching all the DNS
servers
   *and clients* in the world, among other things... So it 'seems'
that it
   is not practical approach. ;P

   Perhaps, It may be interesting a review or a new generation of the
   standard. I, honestly, ignore if this it's being done. Anyway,
given
   what we have today it's *the* long term solution, isn't it? ;P.

   In the meanwhile, we are vulnerable: the open systems world, not
always
   is perfect... ;P

====================
Carlos Veira Lorenzo
     -=o0o0o=-
 Servicios Internet
 Airtel Móvil S.A.
====================
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBN7A+aEj/CaVXSZKlEQKIOACdF74Y7bo4BSrEL6Fw9z+EMwEziSgAnRpu
QlIZlBhOGgaz/TnUFTn/PzHn
=qc06
-----END PGP SIGNATURE-----

<!-- attachment="dnsabuser.c" -->
<HR>
<UL>
<LI>application/octet-stream attachment: dnsabuser.c
</UL>
<HR>
<UL>
<LI>application/octet-stream attachment: xn.sh
</UL>

www.microsoft.com
www.novell.com
www.nrg.be
www.ldg.be
www.mir.es
www.hispasec.com
www.securityfocus.com
www.geocities.com
www.tripod.com
www.hypermart.net

ns1.allinfosys.com
ns2.allinfosys.com
ns.uu.net
dns.ncsa.es
dns2.ncsa.es