Toward the end of Q3 2015, Akamai SIRT began observing limited use of DDoS attacks fueled by Multicast Domain Name System (mDNS) capable devices. The potential for mDNS to become a vector for use in reflection and amplification DDoS attacks was also disclosed on March, 2015.
This advisory details the concept and techniques of the mDNS reflection attack vector as well as how to mitigate it. This attack vector is possible through the availability of source devices that expose mDNS, which is expected on port 5353, over the Internet.
As of October 2016, Akamai has detected and successfully mitigated seven mDNS DDoS attacks against targets in the Gaming and Software & Technology industry verticals. So far, the longevity of this attack may be in question, based on characteristics observed in real-world attacks.
The mDNS attack vector has seen sporadic use since it was first observed in September 2015. As indicated in the timeline below, there was roughly a five-month gap between the initial attack and the next one; this was possibly the result of initial testing of attack scripts. It wasn't until the end of March, early April 2016 that the attack vector began to see more consistent use. However, the attacks using mDNS as a single vector have not been as powerful as other reflection vectors to date.
In the following section, we highlight one attack that occurred in 2016. Of the seven mitigated attacks thus far, none have been against the same target.
The last noted mDNS attack event occurred on October 27, 2016. This was a multi vector DDoS attack consisting of a SYN Flood, UDP Flood, UDP Fragment, DNS Flood, and mDNS Flood peaking at 41 Gbps.
Multicast DNS(mDNS) is a proposed standard protocol released in 2013 as RFC6762. It facilitates the discovery of devices and services, ideally in small networks, without the need for any or minimal user interaction. Because of this, mDNS can also be a suitable component for Zero Configuration Networking (zeroconf). mDNS shares much of the same structure as regular DNS packets, a likely reason for its quick adoption as a DDoS attack vector.
Of course, with the simplicity of a protocol designed to allow a device to be plugged in and ready to go comes some risk. A vulnerability (VU#550620) on mDNS was found by Chad Seaman where mDNS would allow responses to queries originating from outside the local network. These responses then would allow it to disclose information about the affected device, such as its software and services, as well as other potentially sensitive information, suchlike hostname, internal network configuration settings, model number, etc. This feedback can allow a malicious actor to use any mDNS hosts that reply to unicast queries over their Internet-connected interface to participate in Distributed Denial of Service (DDoS) Reflection / Amplification attacks. More information regarding the vulnerability can be found here.
Using a similar concept, the mDNS attack script created by malicious actors sends a specialized unicast query for eliciting a response from mDNS devices. Defined in RFC6763, the service enumeration query is useful for returning all advertised service types on a network. The attack script will generate a payload query of 46 bytes, as shown in the next figure, sending a DNS query for "_services._dns-sd._udp.local" to the vulnerable host; this is meant to return all known services back to the requesting devices. These advertised services can also be queried individually with varying response sizes, offering more opportunity for attackers. However, this tactic would require a more sophisticated attack tool to easily leverage these additional response payloads in a DDoS attack.
The mDNS response payloads observed in DDoS attacks so far have been limited in size. The largest contained 428 bytes of data, 12 bytes fewer than a single NTP monlist data response packet. However, the typical mDNS response size observed has been around the 100-200 byte range. This means the vector is more commonly maxing out at about 4.35x amplification, when considering just the 46 byte request payload and the 200 byte payload response.
The attack script created for mDNS is a modified version of the many scripts available now for UDP reflection and amplification attacks. Its usage is similar as well to the other scripts: simply provide a target IP, target port, list of mDNS devices on the Internet, threads, packet throttle rate, and finally attack run time. The script will then impersonate the target IP when sending the malicious 46 byte queries observed in the next figure through tcpdump.
In our lab test, the queries were sent to a Linux server setup with an mDNS listener. The basic response can be seen in the next figure.
On November 4, 2016, The Shadowserver Foundation completed a mDNS (5353/UDP) scan where 526,245 unique IPs responded to mDNS query. The following graph below represents the top 20 countries and ASNs with mDNS accessible according to the latest scan.
This is one of those protocols that is designed for use within a local network. As such, there should be no reason for exposure of mDNS devices over the Internet. If required, a good practice would be to filter any incoming queries and allow known sources only. An IDS such as Snort can further be used to detect these queries and further mitigate the use of your devices in DDoS attacks. A sample snort detection rule is below.
The mDNS attack vector has seen limited use to date. Like SSDP, this vector would most likely be fueled by devices within a home network. Early attacks have been underpowered but scanning of mDNS port 5353 has been observed on a daily basis over our mitigation platform. Once more devices are enumerated, there is the possibility of larger attacks. Also, like SSDP, based on the unnecessary exposure of this protocol, it is expected that mDNS may not thrive as a DDoS attack vector, as ISPs introduce filtering of this port to home users. Unfortunately, even after years of use, SSDP continues to be leveraged on a daily basis and is still capable of substantial DDoS attacks. This means mDNS attacks may become more powerful before any significant proactive filtering is applied.