On October 22, 2013, Cisco TRAC Threat Researcher Martin Lee wrote about Distributed Denial of Service (DDoS) attacks that leverage the Domain Name System (DNS) application protocol. As Martin stated, the wide availability of DNS open resolvers combined with attackers' ability to falsify the source of User Datagram Protocol (UDP) packets creates a persistent threat to network operators everywhere.

However, DDoS does not operate exclusively in the shadowy world of botnets and open DNS resolvers. It also has become a quasi-legitimate Internet business.  Several sites, colloquially known to the security community as "booters", are for-profit services designed to stress-test networks.  Sometimes operators of these services will purposefully create large DNS records that can be used in their DNS amplification attacks.

For an example of one of these large sized DNS records, consider the domain hizbullah.me.  A small DNS query for the A records at this domain returns more than 240 A records, and returns a total of 3,947 bytes! Any domain possessing more than 240 A records which also happens to lack any MX records is quite suspicious, and will likely serve no other purpose other than facilitating DDoS attacks.  Incidentally, the hizbullah.me domain was registered to a person by the name of  "Kimberley Mently" who lives at the unlikely address of "102 po box" in the city of "Chicago, Virginia".  Kimberly also runs the domains mad.sh (a web hosting service) and hfchaos.net (which presents only a login page).

The recent successes of DNS-based amplification attacks and the low probability of attribution means that future large sustained attacks will almost certainly leverage UDP to create the same powerful amplification and reflection features. There are a number of factors that attackers consider when launching a reflection/amplification attack. First, what is the amplification factor? As previously stated, the DNS amplification factor may be enormous if large DNS records are seeded before the attack or DNSEC records are used. Second is protocol availability. How many Internet servers will respond to a specific protocol request? Over the past two years specifically, threat actors have been exploring these questions and the attack results indicate an expanding repertoire of potent UDP based protocols. Network defenders should take note.

Approximately two years ago Spamhaus was the victim of a large SNMP (Simple Network Management Protocol) amplification attack. Unfortunately just like Open Resolvers, there are hundreds of thousands of SNMP enabled devices that are Internet facing and using a community string of "public". Instead of requesting zone files or resource records (RRs) as is the case with DNS Open Resolvers, an SNMP amplification attack requests management variables which are organized in a hierarchy just like DNS. The variables can be requested in the form of Protocol Data Units (PDUs). Available SNMP Protocol Data Units (PDUs) included in SNMP version 1 include GetRequest, SetRequest, GetNextRequest, Response, and Trap while SNMP version 2 includes two additional PDUs: GetBulkRequest and InformRequest.  Agents listen for UDP requests on port 161. The SNMP Manager receives notifications on port 162.

The Character Generator Protocol (CHARGEN) is another UDP based protocol being leveraged for amplification attacks. CHARGEN is a protocol that is less explicitly used, but may be turned on as part of an IDENT service. CHARGEN listens on port 19 for incoming UDP requests. A CHARGEN attack amplification factor is between 200 and 1000 depending on how it's implemented. The availability of Internet servers running CHARGEN is the only limiting factor for attackers, though the amplification potential appears to make up the relative paucity of CHARGEN availability.

Given this trend of attackers looking for new UDP based application protocols to leverage it's only a matter of time before we see amplification DDoS attacks using Trivial File Transfer Protocol (TFTP), Remote Authentication Dial-In User Service (RADIUS), or Network Time Protocol (NTP).

TFTP has limitations in that an attacker could send a read or write request to a TFTP server on port 69, but the TFTP server would respond to the spoofed source IP address (the victim) with either an acknowledgement packet or data packet (depending on the initial request). Amplification within this protocol isn't optimal for attackers, but if enough TFTP servers are publicly reachable this could still be an effective attack. The TFTP server also responds from an ephemeral port potentially complicating victim mitigation efforts.

RADIUS (ports: 1645 / 1646 / 1812 / 1813) has the same amplification potential as TFTP, the only difference is the response type. RADIUS servers will respond to the "access request" with an "access reject" message. It's unclear how many Remote Access Servers (RAS) are publicly accessible from the Internet to make this an effective attack.

NTP can be leveraged much like SNMP with a larger amplification factor than either TFTP or RADIUS (though we won't discuss how). NTP servers are plentiful so be aware that port 123 UDP traffic may also carry substantial risks.

It's important for network defenders and especially security architecture groups to think through bandwidth saturation and all possible choke points for both ingress and egress traffic. This process needs to happen well in advance of an actual attack. Could your network withstand a 200 GB/second DDoS? Could your upstream Internet Service Provider(s)?  Remember that resource exhaustion is the attacker's goal not just bandwidth exhaustion. Time and money are also important factors when thinking about defending against these types of attacks.

Once an amplification attack is underway blocking UDP from the sourced port (depending on the protocol) on the edge routers is critical as is contacting the upstream provider(s) so that they can do the same. Lastly, attackers can't use reflection servers before they know where those servers/services are located. Threat actors must invest in reconnaissance tools and techniques to properly identify those servers that are going to assist with future attacks. This reconnaissance may take place months before the attack begins so look for an increase in scans for particular UDP services because a large DDoS attack may be just around the corner.

References:
http://www.informationweek.com/security/attacks/is-your-dns-server-a-weapon/240162906
http://dnsamplificationattacks.blogspot.com/2013/07/domain-hizbullahme.html
https://isc.sans.edu/diary/CSAM%3A+ANY+queries+used+in+reflective+DoS+attack/16757
http://www.prolexic.com/ddos-dispatch/eight/Q313-attack-report.html
http://www.spamhaus.org/news/article/678/
https://www.cert.be/pro/docs/chargensnmp-ddos-attacks-rise

Thanks to TRAC Threat Researcher Levi Gundert for co-writing this post.