[iwar] Historical posting
From: Fred Cohen
From: fc@all.net
To: iwar@onelist.com
Mon, Jan 1, 1999
fc Mon Jan 1, 1999
Received: (from fc@localhost) by all.net (8.9.3/8.7.3) id FAA15269 for iwar@onelist.com; Tue, 18 Apr 2000 05:21:43 -0700
To: iwar@onelist.com
MIME-Version: 1.0
Mailing-List: list iwar@egroups.com; contact iwar-owner@egroups.com
Delivered-To: mailing list iwar@egroups.com
Precedence: bulk
List-Unsubscribe:
Date: Mon, Jan 1, 1999
From: Fred Cohen
Reply-To: iwar@egroups.com
Subject: [iwar] Historical posting
The following security advisory is sent to the securiteam mailing
list, and can be found at the SecuriTeam web site:
http://www.securiteam.com
Many name servers are vulnerable to traffic amplification
and NS route
discovery
----------------------------------------------------------------------
----------
SUMMARY
Name servers that accept and forward external DNS queries may be
abused to
behave as traffic amplifiers, threatening network integrity by
bandwidth
saturation (DNS Smurf).
A "deaf" pseudo name server may be used to discover the query chain a
DNS
query takes through various name servers, allowing a trace-route like
route discovery (DNS Traceroute).
This attack is a classic Denial-of-Service attack that can possibly
bring
an entire network to its knees.
DETAILS
Vulnerable systems:
All types of name servers that accept external queries might be
vulnerable. Especially those that forward the queries to other name
servers, or those that have excessive retry attempt values. The common
value for retry is three times, but many misconfigured servers retry
over
20 times when sending out a query packet.
Note that this attack is completely different from the DNS Smurf
attack
discovered by s0ftpr0ject. However, it does exploit weaknesses in
default
<http://www.isc.org/> BIND configurations too.
Impact:
By abusing multiple name server chains as traffic amplifiers an
attacker
can easily saturate any network link. The traffic to the victim IP is
caused by the query packets, which are sent by each name server in the
chain to the fake authoritative name server in the victim network.
For the last few years denial of service (DoS) attacks that are based
on
bandwidth saturation have been a serious problem. A few years ago,
when
the Smurf ICMP denial of service attack got publicly known nearly
everyone
was able to saturate any link by abusing other networks as a traffic
amplifier. Since then numerous amplify attacks have been discovered,
such
as The "
<http://www.securiteam.com/securitynews/Macintosh_computers_can_be_use
d_to_cause_massive_DoS_attacks_on_the_network__Patch_available_.html>
MAC DoS Attack", a x37 traffic amplify attack and DNS Smurf (through
query/answer ratio), the original posting of the Smurf attack is ICMP
ECHO Requests to Broadcast addresses (ICMP Smurf attack).
Any method that allows an attacker to amplify his traffic can be
abused
for a denial of service attack.
Explanation:
When a name server receives a query, most name servers usually start
forwarding the query to some other name servers. There can be quite a
long
path of forwarding queries. However if the query is not resolvable
because
there is no name server listening on the remote host, every forwarding
name server will start to resolve it on their own, by querying the
authoritative name server. In the default configuration each name
server
will send the query three times, after 0, 12 and 24 seconds.
This can be used to discover the path of name servers. To do this an
attacker would query the first name server for a domain he can see the
packets on, at best the domain points to the query host itself. Then
the
attacker would record all name servers that send out a packet to him.
After having done this, the attacker would try with another name
server of
the ones he got queries from. In the best case he will receive queries
from all hosts but one missing. The missing one is the first host in
the
route. After having reduced the list by one he will start over with
the
reduced list until there is only one name server remaining, which is
the
last in the querying chain.
Through seeking especially long paths, where a lot of name servers are
queried, this can be abused as a traffic amplifier attack, as shown
below.
Since the important entries such as the NS entry is in the cache of
each
name server after the first query, the attack is very fast pacing
after
the first query, since no additional packets are sent to the attacker
and
the attacker may spoof the UDP query packets. If the attacker were
clever,
he would use a very short lifetime for his NS entry, while using a
long
lifetime for the victim sub-domain. After the first query succeeded he
will just shut his name server down and send out spoofed query packets
at
a very fast rate.
Example:
The following data is an excerpt from initial tests conducted against
a
vulnerable name server.
08:07:24.943598 ns2.domain > victim.domain: 15121 (35)
08:07:32.747253 ns3.domain > victim.domain: 8536 (35)
08:07:32.832604 ns2.domain > victim.domain: 15121 (35)
08:07:39.819289 ns3.domain > victim.domain: 8536 (35)
08:07:40.670228 ns1.1025 > victim.domain: 56483 (35)
08:07:44.405556 ns4.domain > victim.domain: 5306 (35) (DF)
08:07:48.928981 ns2.domain > victim.domain: 15121 (35)
08:07:52.669825 ns1.1025 > victim.domain: 56483 (35)
08:07:56.107063 ns3.domain > victim.domain: 8536 (35)
08:07:56.471586 ns4.domain > victim.domain: 5306 (35) (DF)
08:08:04.938187 ns6.domain > victim.domain: 26706 (35)
08:08:12.372097 ns5.2187 > victim.domain: 2352 (35)
08:08:13.826464 ns6.domain > victim.domain: 26706 (35)
08:08:16.669021 ns1.1025 > victim.domain: 56483 (35)
08:08:20.603050 ns4.domain > victim.domain: 5306 (35) (DF)
08:08:24.365990 ns5.2187 > victim.domain: 2352 (35)
08:08:30.873233 ns6.domain > victim.domain: 26706 (35)
08:08:32.658479 ns1.domain > querier.1025: 298 ServFail 0/0/0 (35)
08:08:48.369725 ns5.2187 > victim.domain: 2352 (35)
The initial DNS query packet had a size of 35 bytes, although packets
up
to a size of 500 bytes are possible. There are five name servers who
indirectly got the query, which was send by "querier" (query packet
not
displayed). The first name-server that got queried was "ns1".
The query is forwarded to five other name servers, so all together
there
are six name servers that try to resolve the query domain. If the
query
domain is a normal existent domain name, the authoritative name server
will answer promptly and the answer is returned to the original query
host.
This is the normal case. However, if there is an authoritative name
server
that does not respond to the queries sent to it, all name servers will
retry to resolve the domain by sending out the query packet, assuming
the
UDP packet they have previously sent got lost. Because all the name
servers do this, the result is a traffic amplifier with factor 18 (18
packets send for each attacker packet).
Through testing about a few hundred name servers for this
vulnerability,
many name servers were found which will amplify with ratios well
beyond
30, sometimes even exceeding 50.
Solution:
By protecting your own name servers from being abused by attackers you
secure other sites at the same time. If you run BIND name servers in
your
network please care to read basic BIND configuration tutorials and
especially documents on
<http://securityportal.com/cover/coverstory19990621.html> how to
secure
your BIND configuration.
Also notice that you may fall victim to the same attack, if only one
name
server in your network is vulnerable - That means if only one server
is
accepting queries for external domains from strangers, this name
server
inside your network will send out trusted queries to other name
servers in
your network, and hence can be abused too.
By taking more generic measures against being the originator network
of
denial of service attacks, such as improving your overall network
security, you contribute to the security of all other networks in the
Internet too.
In general there is no foolproof method to avoid getting a victim of a
DNS
Smurf. But what can you do if you get attacked?
To think of the correct response we have to think of why this attack
works. It works because other name servers try to query a non-existent
name server in your network and don't get any response, hence retrying
again. To just filter DNS traffic to this IP is only of little use as
a
short-time measure. Instead, setting up a bogus DNS server on the
victim
IP address, which replies with bogus answers to any query it receives
will
reduce the impact of the attack.
However the real cause for the attack is still the number of
misconfigured
DNS servers out there, which accept queries for external domains from
strangers. Another reason is the unreliable transport protocol, which
makes it impossible for the name server to notice the unreachability
of
the remote victim name server.
Exploit:
TESO has created a working demonstration program to exploit the
vulnerability. The program needs Libnet, a low-level network library
installed, which can be obtained through:
<http://www.packetfactory.net/> http://www.packetfactory.net/
Exploit code can be downloaded from:
<http://teso.scene.at/releases/adv3.tar.gz>
http://teso.scene.at/releases/adv3.tar.gz
ADDITIONAL INFORMATION
The information was provided by: <mailto:teso@s... TESO.
See our article regarding Smurf:
<http://www.securiteam.com/securitynews/NetScan_org_raises_awareness_o
n__Smurf_Amplifiers_.html> NetScan.org raises awareness on "Smurf
Amplifiers"
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and
body to: list-unsubscribe@s...
In order to subscribe to the mailing list, simply forward this email
to: list-subscribe@s...
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty
of any kind.
In no event shall we be liable for any damages whatsoever including
direct, indirect, incidental, consequential, loss of business profits
or special damages.
Det. Robert W. Miller
Colorado Internet Crimes Against
Children Task Force
Pueblo High Tech. Crime Unit
Pueblo County Sheriff's Office
909 Court St.
Pueblo, CO. 81003
Tel (719)583-4736
FAX (719)583-4732
mailto:snooker@i...
mailto:cicactf@i...
http://www.co.pueblo.co.us/sheriff/
PGP key available at: http://pgpkeys.mit.edu:11371/
search on snooker@i...