Solved

UDP protocols' vulnerabilities

Posted on 2014-02-10
4
1,459 Views
Last Modified: 2014-02-11
>look for abnormally large responses to a particular IP address

What are the more feasible ways that people out there practise
to mitigate & detect the threat described below?  To look for
large responses is not so feasible.

Should I look out for servers that listen on those UDP ports
& pay particular attention to them?


=============================================
 
National Cyber Awareness System:
TA14-017A: UDP-based Amplification Attacks
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 [1]

NTP      556.9      see: 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 [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
•      [2] NTP Amplification Attacks Using CVE-2013-5211
•      [3] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
•      [4] Ingress Filtering for Multihomed Networks
•      [5] The Spoofer Project
•      [6] An Architecture for Differentiated Services
•      [7] SIP: Session Initiation Protocol
•      [8] New Terminology and Clarifications for Diffserv
Revision History
•      January 17, 2014 - Initial Release
0
Comment
Question by:sunhux
  • 2
  • 2
4 Comments
 
LVL 61

Accepted Solution

by:
btan earned 500 total points
Comment Utility
Will be good to attribute the excerpt and especially it is the whole alert article extracted from US-CERT TA.

Coming back, DDoS is targeting mainly in network bandwidth resources, or  server resources. The alert is more of high network service coming into the victim and overwhelming it beyond it existing capability. Hence making victim service extremely starved or at worst (and maybe to attacker's ultimate agenda) non-functional.

I do encourage you also catch AUS DSD writeup which illustrate the layer defence and control to deter and mitigate the effect of the launch. Basic fundamental to allow necessary service and hardening of the service exposed to internet is critical and fronting the Enterprise with protection capable of robust defending at the perimeter upon detection of such attacks. Better still have the ISP provider to create that initial fronting with established SLA and additional services for clean pipe and even to extend engage content delivery service to maintain acceptable  (if not better) public services availability. Overall candidate are available ranging from CDN to private Cloud based providers namely Akamai, and other DDoS provider CloudFlare, Incapsula, Arbor etc.

It is not just UDP or TCP based on DoS or DDoS. The basic should be already been address as these are considered low hanging like protecting against the "traditional" flooding such as SYN flood, ICMP flood, Teardrop, etc. Service recent exploited also extended to DNS, NTP etc as shared in the article.

One thing to note is that DDoS is not necessary only network based and can be Application based. It has moved up the OSI stack to Layer 7 attacks. These are known port that is allowed by your Firewall and IDS/IPS can help to detect known vulnerability but that is about all, they are not panacea to DDoS attacks.  Some application attack include LOIC, HOIC and going into those of SSL THC brute force to exhaust Web server resource and exploit the protocol anomalies and "hole" inherent in the protocol. The provider should be capable to address it and not purely based on high spikes and bandwidth, such application attacks can be below the configured threshold level and still exhaust server to a slow death. Past example (probably still seeing) are Slowloris, Slow POST etc. It will be good to catch an understanding on application delivery controller (e.g. of article and proposed architecture for reference)

There is no foolproof (and all in one) protection to DDoS, we need to be aware of it first but the layer shared above create the deterence to the attacker end. The latter will also be doing their effort worth count, thinking  many more on their key agenda. It can be a short stint or it can be reputation disaster to victim (as in attack to several well known banks). I see that such attack can be smokescreen for a bigger hidden agenda and modus operandi so do not neglect upkeeping internal layered security protection controls (there can be internal DDoS). Perform the scanning and validation regularly and enforced continuous monitoring for anomalies especially in your critical segment hosting the key eServices and management - it is all about security design and process, not security product and services...

(sidenote - I am not related to any mentioned vendors and just sharing some of their posting that maybe useful)
0
 

Author Comment

by:sunhux
Comment Utility
For a start, what about I just run nmap against my public Internet exposed IP
addresses to see if any of my IPs are listening on those Udp ports & see if
any of those can be shut down if not needed?
0
 

Author Comment

by:sunhux
Comment Utility
So effectively, the same mitigating measures against DDoS can be used
against this DRDoS mentioned in this US-CERT TA ?
0
 
LVL 61

Assisted Solution

by:btan
btan earned 500 total points
Comment Utility
I am suggesting DDoS protection in large and the TA stated reflected scheme is detecting server being part of the zombie group (infected machines) or botnet amplifying the overall DoS impact. It is tough to blacklist such dynamic pool assuming they are assuming dynamic IP and likely also legit source but victimised.

As a whole the morale of the story is to review our defences and focus on
a) Not being exploited as a victim - protecting and hardening your system  
b) Not being unprepared as a target - have measures to deter and mitigate the effect of those attacks
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Today, still in the boom of Apple, PC's and products, nearly 50% of the computer users use Windows as graphical operating systems. If you are among those users who love windows, but are grappling to keep the system's hard drive optimized, then you s…
If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now