The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
DNS Amplification Attacks
------------------------------------------------------------------------
SUMMARY
This paper outlines a Distributed Denial of Service (DDoS) attack which
abuses open recursive Domain Name System (DNS) name servers using spoofed
UDP packets.
This study is based on packet captures and logs from attacks reported to
have a volume of 2.8Gbps. One of the networks under attack indicated some
attacks have reached as high as 10Gbps and used as many as 140,000
exploited name servers. In addition to the increase in the response packet
size, the large UDP packets create IP protocol fragments. Several other
responses also contribute to the overall effectiveness of these attacks.
The risks involved with the recursive name server feature, as well as
those of packet spoofing are well known, yet have been treated more as a
theoretical issue. The attack under study was anticipated as early as
2002. Earlier attacks using queries to non-authoritative servers were for
a reflection attack using MX records. To our knowledge, this is the first
documentation of a new form of a recursive name server reflection attack
designed to use the significantly larger data amplification available from
the extended capabilities of extended DNS standards .In addition to this
attack technique, recursion can be leveraged for other uses such as theft
of DNS resources.
DETAILS
Introduction:
In recent months several attackers massively exploited recursive name
servers to amplify DDoS attacks against several networks utilizing IP
spoofing. Analysis of three of these attacks makes up the bulk of our
study. The addendum to this paper contains a detailed description of three
of these attacks.
The DNS uses a tree-like system of delegations. Recursion is the process
of following the chain of delegations, starting at the Root zone, and
ending up at the domain name requested by a user. A recursive name server
may need to contact multiple authoritative name servers to resolve given
name on behalf of the requester. Recursive name servers are similar to
SMTP relays and web proxies. They all accept messages (including requests
and queries) from clients, which are then forwarded to other servers as
necessary.
Ideally, a recursive name server should only accept queries from a local,
or authorized clients. Unfortunately, many recursive name servers accept
DNS queries from any source. Furthermore, many DNS implementations enable
recursion by default, even when the name server is intended to only serve
authoritative data. We say that a name server is an "open resolver" if it
provides recursion to non-local users.
To establish a perspective, spoofed ICMP attacks are historically well
known. On many of today s networks, ICMP Echo replies (message type 0) can
be seen at the network perimeter. These replies are generated due to
spoofed packets with forged source addresses in the local network space
used in remote attacks.
Similarly, recursive name servers can be induced to participate in DDoS
attacks in a number of ways. A network of computers distributed on the
Internet in a construct such as a Botnet, can send spoofed-address
queries to an Open Resolver (or resolvers) causing it to send responses
to the spoofed-address target. Thereby, the resolver unwittingly
participates in an attack on spoofed addresses. For example, high volumes
DNS SERVFAIL (RCode 2) responses to a spoofed IP address can equal the
damages of spoofed ICMP Echo replies (type 0) without revealing the
identity of the attacker. Relatively small DNS requests can be employed to
cause significantly larger replies from a name server to the spoofed IP
address.
DDoS attacks using recursive name servers can create an amplification
effect similar to the now-aged Smurf attack. The Smurf attack works by
sending an ICMP Echo request (type 8, a ping) to broadcast addresses on
affected networks. These receiving hosts in turn relay the request and a
reply to the spoofed location is initiated. In the Smurf effect, on a
multi-access broadcast network, one can expect every single ping to result
in attack amplification by triggering replies from all the active
computers on the amplification subnet.
The amplification effect in a recursive DNS attack is based on the fact
that small queries can generate larger UDP packets in response. In the
initial DNS specification, UDP packets were limited to 512 bytes. At most,
a 60 byte query could generate a 512 byte response for an amplification
factor of 8.5. This amplification effect has been used in DNS based
attacks for some time (CIAC 1999) (gnupg 2002).
New RFC specifications,- in support of IPv6, DNSSEC, NAPTR and other
extensions to the DNS system, - require name servers to return much larger
responses to queries. This increased UDP payload capability is now being
used to launch attacks with higher UDP response amplifications. These
attacks employ the RFC 2671 (Extension Mechanisms for DNS - EDNS)
specification to implement a mechanism whereby the request initiator can
advertise a larger UDP buffer size to responders by using an OPT pseudo-RR
in the additional data section of the request.
Thus, where the amplification of a standard Smurf attack relies on sending
a packet to a broadcast address which then causes multiple systems to
respond to a victim, DNS amplification occurs due to the response packet
being significantly larger than that of the query. If an Open Resolver
receives an EDNS (RFC 2671) query containing a large buffer advertisement,
its reply to the possibly-spoofed requesting IP address can be quite
large. A DNS query consisting of a 60 byte request can be answered with
responses of over 4000 bytes amplifying the response packet by a factor of
60.
Both the attacked party and the exploited servers participating in the
attack - the recursive name server (or servers) - can potentially
experience a serious DDoS attack. One report on NANOG (NANOG #1) describes
a deluge of DNS requests to an exploited server with some addresses
making more than 250,000 requests in a short time frame. The server in
this report was participating in one of the attacks which we study in this
paper. In our case study the DNS entries have a long TTL
(minimum-ttl:86400s (24 hours)) to force the exploited servers to cache
the real authoritative name server s resource records.
We assume this was an attempt to avoid a DDoS on the real authoritative
name server.
By combining different response types, the amplification effect can reach
up to a factor higher than 60. If, for example, the response consists of a
122 byte A type response, a 4000 byte TXT response, and a 222 byte SOA
response, the total response consists of 4320 bytes. This yields an
amplification factor
of 73.
Other amplifications are possible depending on the query size and the
experienced packet distributions in an actual attack. Due to networking
limits, traffic collisions and other factors, the effective rate of an
attack will be significantly smaller than the amplification s theoretical
upper limit.
The full paper can be found at :
<http://www.isotf.org/news/DNS-Amplification-Attacks.pdf>
http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
ADDITIONAL INFORMATION
The information has been provided by <mailto:ge@linuxbox.org> Gadi Evron
and <mailto:Randy_Vaughn@Baylor.edu> Randal Vaughn.
The original article can be found at:
<http://www.isotf.org/news/DNS-Amplification-Attacks.pdf>
http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
========================================
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@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
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.
