The Cost of Convenience: Multicast DNS and Your Privacy

Every time you connect to a Wi-Fi network, there’s a hidden risk to you and your device’s privacy, all thanks to a networking protocol designed to make life easier. Let’s explore Multicast DNS (mDNS) and the ways that ease-of-use networking can introduce security risks.

Modern networking has become a complex labyrinth of moving parts that can be a headache to navigate. As enterprises continue to introduce new technologies and devices into their LAN infrastructure, making sure that everything can communicate effectively brings new obstacles. While larger organizations have dedicated infrastructure to support protocols like name resolution across hundreds of machines hosted in several subnets, your local mom and pop coffee shop may just want its clientele to be able to join the guest Wi-Fi network and for its Point-of-Sale system to have the Internet connectivity required to process payments. This is where the privacy risks associated with mDNS truly shine.

ZeroConf Proposed an Easy Solution

First, we need a quick history lesson. The wide variance in the needs of businesses with differing sizes and staff with technical know-how has manifested a need for user-friendly methods for connecting new devices to the network. This has been a driving force behind the Internet Engineering Task Force’s Zero Configuration Networking (ZeroConf) initiative, which has been creating and publishing protocols that automatically discover and configure devices for network connectivity since the late 90s.

The Multicast DNS (mDNS) protocol was designed as a ZeroConf solution to support local networks that have no local DNS authority. Its original intent was to make home networking a less cumbersome task for consumers with Apple products, such as the Bonjour printer and host discovery service. Automating these processes for non-technical users quickly gained popularity among consumers, which in turn increased the number of MNR protocol queries propagating in home networks.

mDNS: DNS Without the Overhead

Now that we know why mDNS was created, let’s discuss its use in modern networking. DNS uses a pre-defined, hierarchical query structure to resolve a hostname to an IP address, whereas mDNS, as its name implies, uses a multicast packet to query all hosts in the network to resolve a hostname. Notably, this removes the need for a dedicated DNS server, as each host is able to identify and query one another instead of using a central, authoritative set of hostnames and IP address records.

mDNS and DNS employ separate naming conventions; mDNS will append the “.local” Top-Level Domain and use it it perform multicast name resolution. This is helpful in home and small business networking, wherein a full DNS server is unlikely to be found. Likewise, mDNS resolution is constrained to the LAN, and typically the subnet of the originating request. This is not to say that it cannot propagate beyond subnetting, but this typically requires a rule to be configured to allow it specifically.

Some popular technologies you may be familiar with leverage mDNS to promote “plug and play” user-friendly connectivity. Apple products have been reliant on the protocol as a component of its Bonjour service, enabling automated discovery of printers and hosts as well as file sharing. With Apple’s use of mDNS gaining traction, and companies like Google adopting it for their devices, Microsoft also added mDNS support to Windows 10, in version 1703. This implementation was originally employed primarily as an automated printer discovery utility, again aiming to reduce the overhead associated with connecting new devices to the network. Over time, Windows has expanded its utility to include hostname resolution in a similar manner to Bonjour, further increasing the frequency of mDNS queries in LANs.

When Personal Devices Meet an Enterprise Network

As more users adopted devices with mDNS at home, it started to appear in enterprise networks as businesses implemented BYOD policies, allowing staff to connect personal devices to organizational WLANs. While this solution lowers expenses associated with providing and maintaining mobile devices specifically for work-related applications, it does present some unique and often overlooked security gaps.

Organizations often place an emphasis on securing their private WLANs, employing controls such as rogue AP and client detection and 802.1x authentication. This, combined with traditional firewall implementations limits the potential for an attacker to gain unauthorized access to the network and, in the context of this article, the ability to listen for mDNS queries.

An Open Guest network however, may not be as well protected. Just as mDNS is designed to make configuring network-connected devices hassle-free, many Guest networks are deployed in a manner that favors usability over security. Considerations such as multicast network protocols, encrypted transmission, and authentication are often unaddressed in Open network, manifesting in a thorn in an otherwise secure organization’s paw.

Privacy Concerns with mDNS

Now that we’ve covered the history of mDNS and some of its most notable impelementations, let’s discuss the risks it presents to users both across enterprise, home, and guest Wi-Fi networks. While mDNS does offer ease-of-use benefits in LAN host and service discovery, it does present several major security considerations that should be recognized. In order to illustrate these concerns, let’s dive into how the protocol actually works with some real world examples, tying each risk to the MITRE ATT&CK Framework. The following image shows an mDNS packet captured from a home Wi-Fi network:

As shown above, mDNS will freely advertise the hostname of the querying asset. While this may seem rather benign in nature at first glance, let’s consider a common configuration used by larger enterprises today. While most organizations employ security controls to restrict access within their wireless LAN, many businesses will also offer a Guest Wi-Fi network as an option for visitors and clientele. This is often left in an Open state, requiring no authentication and providing no encryption between the AP and the client. At first, the security risks may not be clear; if an organization segregates its Guest traffic from the staff WLAN, what’s the problem?

Issues arise when one begins to consider the privacy of both its guests and its staff. Let’s say that an organization has a Bring Your Own Device (BYOD) policy for staff, where they use their personal devices to interface with various network resources. Within the context of the staff WLAN, which has been properly secured via 802.1x, this is not a concern; however, the likelihood that staff will connect to the Guest network at some point in time is more likely than not.

Say a staff member has their device (be it a phone, laptop, tablet) connected to the Guest network, and an attacker is able to capture an mDNS query.

Depending on the way the device and the network are configured, this can provide a threat actor with access to the Guest network with a few vital data points:

1. If the device is configured with a hostname that ties the user to the company, the attacker can better pinpoint the focus of an attack.

   Naming conventions can reveal a lot about how an organization configures its infrastructure. Let’s consider the scenario in which an organization has a CEO named John Smith, and his work device is named jsmith-iphone [T1592.001]. A threat actor that captures an mDNS query from this device can now, with a reasonable amount of certainty, deduce the naming convention of the company’s users, and also knows that John is likely nearby [T1589.002]. While this raises obvious privacy concerns in the context of phishing (or in this case, whaling) campaigns, it can also be used to identify the user’s approximate location.

2. As hosts on the network make mDNS queries, an attacker can send spoofed responses, opening the door to Man-in-the-Middle attacks.

   This provides an even larger attack surface, wherein a threat actor may sit and wait for a query to be made via Wi-Fi and send a response claiming to be the resource the querying host is searching for. If successful, the attacker may be able to intercept traffic from the victim.

As shown above, the security implications associated with mDNS can be quite severe within the context of a publicly accessible Wi-Fi network.

MITRE ATT&CK Framework References

A Threat Actor’s Playground

Aside from the aforementioned privacy concerns, mDNS also provides an attacker with a myriad of information and utility that can be leveraged to enumerate a network, and capture NTLM authentication from a victim. Let’s take a look at each of these threats and map them to the MITRE ATT&CK Framework.

In the event that an attacker were to gain Layer 3 access to a network, be it through exploitation of a web application, successful phishing campaigns, or simply by plugging a Raspberry Pi into a live ethernet port, they will immediately attempt to enumerate the devices visible to it and begin mapping the attack surface.

Traditionally, tools like nmap and masscan have been the go-to for threat actors and penetration testers alike to quickly identify hosts on the network and their running services. Using TCP port scanning, one can quickly enumerate the landscape of a given network and focus attacks on the most appealing targets. While this is an effective method of enumeration, modern XDR and firewall vendors have become privy to their use by attackers and are likely to either alert SOC staff or provide false results via rate limiting.

In response, attackers have become resourceful and transitioned to “living off the land”, leveraging information readily available to them to perform enumeration. As mentioned previously, mDNS provides a veritable treasure trove of information to anyone listening for it, including hostname and IP address. Even more enticing to the attacker, listening to these queries is essentially undetectable, and thus sitting idly on the network can, over some time, result in the mapping of much of a network’s infrastructure [T1592].

Even more concerning is the ability to capture and relay NTLM authentication handshakes via MNR Protocol Poisoning. Through nothing more than answering mDNS queries as they propagate throughout the network, an attacker can impersonate a network resource and force the victim to authenticate over NTLM, which can then be used to facilitate unauthorized access to a litany of services and even host compromise [T1040] [T1557.001].

While we won’t dive into the minutiae of this attack vector here, it should be noted that this is an extremely common vulnerability exploited in the wild consistently and can lead to compromise of a domain strictly from Layer 3 network access [T1003].

MITRE ATT&CK Framework References

mDNS in the Wild

So, now that we understand the risks associated with mDNS, we should take a deeper look into its frequency within modern networks. mDNS queries are prevalent across enterprise LANs of various sizes, primarily in part due to the sheer number of technologies that use it as a discovery protocol. Smart phones and TVs, game consoles, applications that support remote streaming like Spotify and YouTube, and many modern printers all use the protocol as a resolution method.

Of ~460,000 MNR queries captured across four enterprise LANs of various size and scope, the following chart illustrates the frequency of mDNS with respect to the other two protocols. First, organizations classified as “large”, with over 500 staff:

And second, smaller organizations, averaging between 50-200 employees:

As shown above, mDNS is often the most frequently queried of the three MNR protocols, regardless of network size. If your organization has MFDs, Apple Products, or modern Windows workstations and servers, it’s a safe assumption that something in the network is likely making mDNS requests.

The Primary Offenders

Open Wi-Fi networks have become a staple of many organizations of various sizes. While securing your organization’s Guest network might help to protect your staff and clientele’s privacy, the restaurant down the street that all of your users flock to during lunch may not be security conscious.

In general, businesses which receive large influxes of public traffic are more likely to employ Open networking. This may include Universities, hotels, restaurants, and large public venues. As a rule of thumb, any publicly-accessible business that advertises free Wi-Fi can generally be lumped into this group of potentially vulnerable Open networks.

Users who frequent these establishments should exercise vigilance when connecting to the Guest network and employ the following recommendations to better secure their privacy.

Tackling the mDNS Debacle

Hostname Hygiene

Now that we’ve addressed the risks associated with mDNS, let’s discuss the ways to protect you and your staff against it. As we discussed previously, within the context of a Guest network one of the more prominent data points advertised by mDNS is hostnames. These privacy concerns can be mitigated largely through enforcing a policy in which staff are required to employ hostnames that do not reveal any identifying information about the user. Ideally, hostnames should be ambiguous and not able to be tied to a specific user.

Disabling mDNS at the Host Level

mDNS can be disabled across the workstation and server population via a startup script that sets the following registry key using both PowerShell and cmd.exe:

Disable mDNS using PowerShell:

set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name EnableMDNS -Value 0 -Type DWord

Disable using reg command in cmd.exe:

REG ADD  "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v " EnableMDNS" /t REG_DWORD /d "0" /f

This is a great first step in tackling mDNS with the LAN, but should not be construed as a panacea. Limiting the number of hosts that can make mDNS queries is part of the battle, but disabling it at the network level is undeniably more effective.

It should also be noted that disabling mDNS on some devices is not possible on some devices. For example, most Apple devices do not provide a simple solution for disabling the protocol, including mobile devices like iPhones and iPads. The same is true for many “smart” devices, such as that TV in your conference room that staff use for Teams meetings or the Xbox in the break room. In order to mitigate the risks associated with mDNS, a network-level solution must be employed.

Securing Guest Wi-Fi with Opportunistic Wireless Encryption (OWE)

As with most security controls, engineers and administrators are forced to navigate a tenuous path of enforcing security without needlessly complicating or negatively impacting the end-user experience. Networking, and more to the point, network authentication such as 802.1x can generate a lot of headaches for staff that aren’t familiar with its implementation.

HPE Aruba has introduced Wi-Fi CERTIFIED Enhanced Open with Opportunistic Wireless Encryption (OWE) as an easy-to-deploy solution for Open networking to provide encryption without the hassle of logging in. Open System Authentication (OSA) is used to generate a unique encryption key that is shared between the AP and client, which is then used to encrypt a second set of keys that are used to secure all traffic.

While OWE alone won’t stop mDNS from propagating within the network, this is an extremely effective mitigator against Man-in-the-Middle attacks, such as those discussed previously with regard to Guest networks. Enforcing WPA3 encryption on Guest traffic can help bring your Open networks in line with the security controls you use to secure your staff WLAN, decreasing the overall attack surface of the facility and closing a vulnerability gap that often goes unnoticed.

Eradicating MNR via Client Isolation

In addition to Enhanced Open with OWE, HPE Aruba also provides a method for eliminating multicast traffic in Wi-Fi networks at the AP itself. Client Isolation effectively eliminates P2P traffic within a WLAN, routing all traffic to the AP and prohibiting communication between connected devices. Disabling connectivity between hosts in the network curtails any propagation of MNR protocol queries, including mDNS.

Now, not every Wi-Fi network will be suitable for Client Isolation, as sometimes direct connectivity between hosts may be necessary, such as with shared printers. This may present a good opportunity to set up multiple SSID’s, one for strictly Guest access employing Client Isolation, and one for the devices that may rely on direct communication that doesn’t. The end goal is to secure all of the Guest access that you can while still maintaining functionality for staff and visitors wherever possible.

Addressing mDNS at the Network Level

To block multicast/broadcast poisoning effectively, network administrators need to understand the role of mDNS (Multicast DNS) in local network communication. It works by using multicast messages sent over UDP port 5353.

• For IPv4, mDNS utilizes the multicast address 224.0.0.251.
• For IPv6, mDNS operates over the multicast address FF02::FB.

In most, if not all enterprise environments, there is no reason to allow mDNS traffic, as it can introduce unnecessary security risks. It should be considered a non-essential protocol in managed networks and should be blocked at the network level to reduce exposure.

Blocking IP addresses via Access Control Lists is an easy and intuitive process on modern networking equipment, and HPE Aruba’s AOS-CX operating system makes the process of establishing deny rules for the two multicast addresses simple:

switch(config)# access-list ip disable-multicast-namev4
switch(config-acl-ip)# 20 deny any any 224.0.0.251
switch(config-acl-ip)# 25 deny any 224.0.0.251 any
switch(config-acl-ip)# exit

switch(config)# access-list ipv6 disable-multicast-namev6
switch(config-acl-ip)# 20 deny any any ff02::fb
switch(config-acl-ip)# 25 deny any ff02::fb any
switch(config-acl-ip)# 30 permit any any any
switch(config-acl-ip)# exit
switch(config)#

By blocking traffic to these IP addresses at either the Access Point or Aruba Central’s administrative WLAN console, your organization can effectively eliminate mDNS from the network entirely. We would caution that this should likely be configured over a period of time using staged testing and rollouts, as some applications and devices such as printers, smart TVs, and kiosks may be configured to rely on the protocol and require adjustments to instead solely resolve resources via DNS.

Shaping Your Network

You may be asking yourself at this point, if mDNS is so insecure, why would anyone leave it enabled? As we discussed previously, mDNS does offer value for organizations that employ Apple machines and IOT devices, and services such as Bonjour are reliant on it. While the remediations presented in this article are the most effective mitigators against the evils of mDNS, we would be remiss if we did not describe some additional methods for tuning your network environment to both support the protocol where its needed and locking it down where it isn’t.

Utilities such as AirGroup provide the flexibility to control how far mDNS can propagate within your network at a subnet level, and even offer granular controls such as allowing it to only reach hosts that are assigned specific roles. This is invaluable for organizations that often require services like the aforementioned Bonjour, such as educational institutions.

Each organization’s mission will shape the way that network administrators tune its multicast traffic. Some may decide that its best to completely disable it, and some may find that printing and host discovery services are not functional without it. HPE Aruba support is always available to field questions regarding network tuning and functionality to ensure that you’re able to make informed, security-conscious decisions without compromising function.

Conclusion

mDNS was originally designed as a protocol to help make networking easier. Unfortunately, as any security professional will echo, any technology designed with plug and play in mind will likely introduce some level of insecurity, and MNR protocols embody that notion fully.

Although mDNS does provide value in networks that are heavily reliant on IOT devices, the attack surface that its existence provides heavily outweighs its benefits in most cases. Technologies developed with ZeroConf in mind are typically the most vulnerable, and thus should be treated as a liability rather than a helping hand. While there are several methods available to help curtail the propagation of mDNS and combat the risks to privacy it presents, the most effective resolution begins and ends at the network level. Using tools like HPE Aruba’s OWE and ACLs, an organization can better secure both its LAN and WLAN infrastructure and defang any attack vector associated with mDNS for good.

Just as we saw with the hidden risks of connecting to a Wi-Fi network, the convenience of mDNS should not come at the cost of your privacy. In today’s networked world, it’s crucial to recognize the trade-off between ease of use and the security of your data. Addressing mDNS head-on and securing your network will help ensure that convenience doesn’t come at the expense of your privacy.