[SECURITY-L] TA14-017A: UDP-based Amplification Attacks

Seg Fev 10 11:35:15 -02 2014

-------- Original Message --------
Subject: 	TA14-017A: UDP-based Amplification Attacks
Date: 	Sun, 09 Feb 2014 12:24:40 -0600
From: 	US-CERT <US-CERT em ncas.us-cert.gov>
Reply-To: 	US-CERT em ncas.us-cert.gov
To: 	security em .unicamp.br

TA14-017A: UDP-based Amplification Attacks

NCCIC / US-CERT

National Cyber Awareness System:

TA14-017A: UDP-based Amplification Attacks
<https://www.us-cert.gov/ncas/alerts/TA14-017A>
01/17/2014 03:22 PM EST

Original release date: January 17, 2014 | Last revised: February 09, 2014

      Systems Affected

Certain UDP protocols have been identified as potential attack vectors:

  * DNS
  * NTP
  * SNMPv2
  * NetBIOS
  * SSDP
  * CharGEN
  * QOTD
  * BitTorrent
  * Kad
  * Quake Network Protocol
  * Steam Protocol

      Overview

A Distributed Reflective Denial of Service (DRDoS) attack is an emerging
form of Distributed Denial of Service (DDoS) that relies on the use of
publicly accessible UDP servers, as well as bandwidth amplification
factors, to overwhelm a victim system with UDP traffic.

      Description

UDP, by design, is a connection-less protocol that does not validate
source IP addresses.  Unless the application-layer protocol uses
countermeasures such as session initiation, it is very easy to forge the
IP packet datagram to include an arbitrary source IP address [7].  When
many UDP packets have their source IP address forged to a single
address, the server responds to that victim, creating a reflected Denial
of Service (DoS) Attack.

Recently, certain UDP protocols have been found to have particular
responses to certain commands that are much larger than the initial
request.  Where before, attackers were limited linearly by the number of
packets directly sent to the target to conduct a DoS attack, now a
single packet can generate tens or hundreds of times the bandwidth in
its response.  This is called an amplification attack, and when combined
with a reflective DoS attack on a large scale it makes it relatively
easy to conduct DDoS attacks.  

To measure the potential effect of an amplification attack, we use a
metric called the bandwidth amplification factor (BAF).  BAF can be
calculated as the number of UDP payload bytes that an amplifier sends to
answer a request, compared to the number of UDP payload bytes of the
request.

The list of known protocols, and their associated bandwidth
amplification factors, is listed below.  US-CERT would like to offer
thanks to Christian Rossow for providing this information to us.

*Protocol* 	*Bandwidth Amplification Factor* 	*Vulnerable Command*
DNS 	28 to 54 	see: TA13-088A
<http://www.us-cert.gov/ncas/alerts/TA13-088A> [1]
NTP 	556.9 	see: TA14-013A
<http://www.us-cert.gov/ncas/alerts/TA14-013A> [2]
SNMPv2 	6.3 	GetBulk request
NetBIOS 	3.8 	Name resolution
SSDP 	30.8 	SEARCH request
CharGEN 	358.8 	Character generation request
QOTD 	140.3 	Quote request
BitTorrent 	3.8 	File search
Kad 	16.3 	Peer list exchange
Quake Network Protocol 	63.9 	Server info exchange
Steam Protocol 	5.5 	Server info exchange

      Impact

Attackers can utilize the bandwidth and relative trust of large servers
that provide the above UDP protocols to flood victims with unwanted
traffic, a DDoS attack.

      Solution

    DETECTION

Detection of DRDoS attacks is not easy, due to their use of large,
trusted servers that provide UDP services.  As a victim, traditional DoS
mitigation techniques may apply.

As a network operator of one of these exploitable services, look for
abnormally large responses to a particular IP address.  This may
indicate that an attacker is using your service to conduct a DRDoS attack.

    MITIGATION

*Source IP Verification*

Because the UDP requests being sent by the attacker-controlled clients
must have a source IP address spoofed to appear as the victim’s IP, the
first step to reducing the effectiveness of UDP amplification is for
Internet Service Providers to reject any UDP traffic with spoofed
addresses. The Network Working Group of the Internet Engineering Task
Force (IETF) released Best Current Practice 38 document in May 2000 and
Best Current Practice 84 in March 2004 that describes how an Internet
Service Provider can filter network traffic on their network to reject
packets with source addresses not reachable via the actual packet’s path
[3][4].  The changes recommended in these documents would cause a
routing device to evaluate whether it is possible to reach the source IP
address of the packet via the interface that transmitted the packet. If
it is not possible, then the packet most likely has a spoofed source IP
address. This configuration change would substantially reduce the
potential for most popular types of DDoS attacks. As such, we highly
recommend to all network operators to perform network ingress filtering
if possible.  Note that it will not explicitly protect a UDP service
provider from being exploited in a DRDoS (all network providers must use
ingress filtering in order to completely eliminate the threat).

To verify your network has implemented ingress filtering, download the
open source tools from the Spoofer Project
<http://spoofer.cmand.org/index.php> [5].

*Traffic Shaping*

Limiting responses to UDP requests is another potential mitigation to
this issue.  This may require testing to discover the optimal limit that
does not interfere with legitimate traffic.  The IETF released Request
for Comment 2475 and Request for Comment 3260 that describes some
methods to shape and control traffic [6] [8].  Most network devices
today provide these functions in their software. 

      References

  * [1] DNS Amplification Attacks
    <http://www.us-cert.gov/ncas/alerts/TA13-088A>
  * [2] NTP Amplification Attacks Using CVE-2013-5211
    <http://www.us-cert.gov/ncas/alerts/TA14-013A>
  * [3] Network Ingress Filtering: Defeating Denial of Service Attacks
    which employ IP Source Address Spoofing
    <http://tools.ietf.org/html/bcp38>
  * [4] Ingress Filtering for Multihomed Networks
    <http://tools.ietf.org/html/bcp84>
  * [5] The Spoofer Project <http://spoofer.cmand.org/index.php>
  * [6] An Architecture for Differentiated Services
    <http://tools.ietf.org/html/rfc2475>
  * [7] SIP: Session Initiation Protocol
    <http://tools.ietf.org/html/rfc3261>
  * [8] New Terminology and Clarifications for Diffserv
    <http://tools.ietf.org/html/rfc3260>

      Revision History

  * January 17, 2014 - Initial Release

------------------------------------------------------------------------

This product is provided subject to this Notification
<http://www.us-cert.gov/privacy/notification> and this Privacy & Use
<http://www.us-cert.gov/privacy/> policy.

------------------------------------------------------------------------
OTHER RESOURCES:
Contact Us <http://www.us-cert.gov/contact-us/> | Security Publications
<http://www.us-cert.gov/security-publications> | Alerts and Tips
<http://www.us-cert.gov/ncas> | Related Resources
<http://www.us-cert.gov/related-resources>

------------------------------------------------------------------------
This email was sent to security em unicamp.br using GovDelivery, on
behalf of: United States Computer Emergency Readiness Team (US-CERT) ·
245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110
Powered by GovDelivery <http://www.govdelivery.com/portals/powered-by>

----- End forwarded message -----