After the preliminary study denial of service (DoS) cyberattacks alongside any of their variants set out in the article “DrDoS: characteristics and operation“, this new article is going to address how the mDNS protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.
The purpose of the multicast DNS protocol (mDNS) is to convert host names into IP addresses without the need for prior name resolution configuration. It is designed to be used on small local networks without a local Domain Name server (DNS), but which need name resolution to interconnect the devices in them, such as printers, scanners and IP telephones, among others.
In mDNS, unlike DNS, the devices send their resolution queries by multicast to the whole network segment on which the devices are registered. The device, whose name matches the query, returns its IP address through multicast so that the machine that made the query and the rest of the devices that are listening register it temporarily in their DNS cache. This makes it possible to speed up name resolution and reduce multicast traffic when a new request is made.
- Figure 1. mDNS operational diagram. -
These multicast communications are done through UDP (User Datagram Protocol), through port 5353, and their operating specifications are described in RFC 6762 and RFC 6763, which set out and standarise some initiatives such as “Bonjour” (Apple), LLMNR (Microsoft) and Avanhi (a Linux free community), which are used to implement name resolution in “Zeroconf “or” Zero Configuration Networking “(Zero-Configuration Networking) technology. These specifications also allow the devices to advertise their services, such as printing.
The attacker’s aim is to send en masse name resolution query requests from outside the local network by exploiting the UDP connectivity of the mDNS protocol and the accessibility to port 5353 from outside to achieve a denial-of-service condition.
To do so, the cybercriminal carries out request source IP spoofing, assigning it to the victim machine, and it uses a network of machines (botnet) to send requests from the external local network, thus achieving a reflected and amplified attack. In that amplification, the size at source of each query packet, 46 bytes, is multiplied by between 4 and 10 when they reach the victim. As a result, the system becomes saturated and cannot manage the responses or it ceases to provide its service.
- Figure 2. mDNS DrDoS attack diagram. -
Besides the impairment to the functioning of the attacked network, the vulnerability of mDNS may allow the attacker to extract the data exchanged between the devices on the local network, such as the name of the host or the network addresses. The cybercriminal thus obtains valuable information from the system, which can help him/her carry out other, more effective and precise attacks.
Since it is a protocol designed to be used within a local network, the mDNS devices must not be exposed to risks on the Internet. Should the opposite occur, it is recommended that you filter the incoming queries using a firewall to allow only legitimate ones. Any exposed mDNS server on the Internet will be vulnerable to the attack. This can be modified using the following command:
nmap -Pn -sU -p5353 --script=dns-service-discovery <IP-server>
If the mDNS device turns out to be vulnerable, it is recommended that you follow the following guidelines to prevent it from being able to be used voluntarily as part of the platform of a DrDoS attack on a third party:
- Disable mDNS resolution. By definition, any computer that has mDNS domain name resolution activated is liable to be a victim of this attack, hence deactivating the service is essential.
- Ask your Internet service provider (ISP) for anti-spoofing filters. ISPs may reject portmap traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent mDNS-associated traffic from receiving and processing queries that are liable to be a DrDoS attack through this protocol.
- Configure the mDNS service behind a firewall. The firewall must be configured with rules that detect and filter unsolicited requests sent by UDP, including “whitelists” and anti-spoofing IP configuration.
- Limit the visibility of mDNS devices on the Internet. Wherever possible, it is advisable to limit access to the machines that have mDNS resolution enabled so that they are not “public”, normally by filtering using a firewall the IP addresses that may access the server.
- Deployment of intrusion and blocking systems (IDS/IPS). A Security Information and Events Manager (SIEM) would make it possible to identify anomalies in the traffic originating or destined for port 5353 and quickly to detect them to apply an immediate response, thus preventing possible attacks.
- Set out an action protocol for mDNS DrDoS incidents: have a plan of pre-existing action that allows for a quick and effective response to prevent any greater impact on the system.
- Keep systems up-to-date and patched. This prevents exploitation of other vulnerabilities that could lead to a DrDoS attack on computers using the mDNS service.
Detection and evidence
The signs of a device affected by this type of attack may be found by checking for excessive consumption of the machine’s resources, as regards use of the processor, RAM and disk access. For this verification it is very useful to review the data obtained from the machine health monitoring tools deployed in the infrastructure.
Evidence of an attack can also be found in the network monitoring alerts, mainly analysing traffic related to port 5353.
On the other hand, it is also possible to find in the logs affected devices traces of the event, should it have gone unnoticed at the time of the attack and there are suspicions that it had taken place. The associated logs are accessible depending the platform of the operating system on which it runs. To find out where these audit logs are stored, see the relevant manufacturer’s documentation.
Response and recommendations
Once the execution of the DrDoS attack on proprietary mDNS devices has been confirmed, the pre-defined action and incident management protocols must be put into practice. It is recommendable to include the following points in them::
- Review the source of the source and destination IP addresses, as well as destination ports and mDNS traffic URL addresses: collect all the information that may be useful to report it to the ISP so that it can block it.
- Blocking and filtering of unwanted traffic. The data collected previously will make it possible to configure filtering rules in firewalls and routers to prevent requests arriving aimed at the own 5353 port. It is recommended you contact your Internet and hosting provider to apply these filters.
- Obtain technical assistance: contact the IT technical services suppliers contracted through the leading public CERTs, such as INCIBE-CERT.
On the other hand, it is also important to act quickly, since the organisation may face complaints from the victim of the attack due to its repercussions.
Once the cyberattack has ceased and the service has been restored to normal, it is recommendable to analyse what caused it, identify possible vulnerabilities and set out a bastioning plan to prevent it from happening again.