One of my most valuable but frustrating tools is Wireshark.
Valuable: easy to slice and dice through network packet capture (PCAP) data. It’s like a network microscope on steroids. I can’t tell you how many times I’ve been able to identify an issue by analyzing a PCAP file.
Frustrating: network traffic can be extremely noisy. I have to sort through warehouses of haystacks before I can even begin to start looking for needles. (Luckily, Wireshark’s filtering capability is powerful, but it takes time, and every environment has its own network noise profile.)
When I’m working through a packet capture, my first goal is to filter out all of the things I know I don’t care about. And until the past few years, one of the biggest offenders on the network for Windows machines was the Link-Local Multicast Name Resolution, or LLMNR, protocol.
Eventually, the bad guys figured out that this chatty protocol could be abused, and it earned its name on the list of Things You Should Turn Off On Windows Systems. Luckily there’s a Group Policy setting for disabling LLMNR, which makes it easy to roll out across a traditional Windows enterprise environment in a traditional corporate network.
While all of that was going on, as Johannes Ulrich wrote recently on the SANS ISC blog, the folks over at Apple developed the “Bonjour” protocol, which enabled network discovery of services for everything from music to printers to point-to-point streaming, i.e. Airplay. Because Apple operates a relatively closed ecosystem for its devices, it tends to develop features that are easy to use and zero-touch — “it just works” traditionally hasn’t applied to Windows systems.
The underlying technology for Bonjour — multicast DNS (mDNS) — gained traction where other discovery protocols, like LLMNR, did not, and eventually found its way into Apple’s iPads and iPhones, in addition to traditional Mac desktops and laptops. Today, it’s also found in Linux and Windows systems, which we’ll return to in a minute.
Ulrich’s blog post notes that Apple recently had to patch the iPad and iPhone due to a vulnerability associated with mDNS, where the developers forgot to implement MAC address randomization — presenting a random hardware address to each network, rather than the device’s real hardware address, to protect a user from being tracked. (Imagine if you use the public wifi at Coffee Shop A and Bookstore B. With randomization, your iPhone has MAC address A at Coffee Shop A, but MAC address B at Bookstore B; if the coffee shop and bookstore share their wifi records, they can’t correlate your device’s two addresses as one actual device. Without randomization, they can “track” you across both wifi networks because your device address is the same.)
So how do we get from Wireshark and an Apple patch for mDNS to the title of this post, “Why you should not” disable mDNS; or, why Microsoft gave up on mDNS security?
Last year, Microsoft wrote in a blog post titled “mDNS in the enterprise.” They sing the praises of their arch nemesis (or at least one of them…possibly a toss-up between Apple, in the devices and OS space, and Amazon, in the cloud space) for developing Bonjour into the easy-peasy zero-configuration network discovery protocol it is today, and note that it’s been rolled into Windows for all of the trappings of today’s connected smart homes: speakers, displays, printers, set-top boxes, and screen sharing and mirroring. To quote the author, James Kehr: “Our modern connected life wouldn’t be the same without mDNS. […] Everyone in the tech industry loves mDNS, whether they know the protocol exists or not … except corporate security.”
Recently, when chewing through PCAP files in Wireshark, I’ve found a ridiculous amount of mDNS traffic, both inbound and outbound, in Windows environments. From a filtering standpoint, it’s an easy problem to whack, given that mDNS is on 5353/udp. But it bulks up the PCAP files unnecessarily. And it reveals a second problem: mDNS is so popular, many applications bring their own support for it (*cough*Google Chrome*cough*), and on Windows systems, that means applications are bypassing Windows’ built-in DNS client.
From the blog post: “There is a magic registry value in Windows that will disable mDNS in the Windows DNS client resolver. I am not going to tell you what it is, but I will tell you why you should not rely on it to disable mDNS.”
And if that’s not clear enough: “Warning! Disabling mDNS can have unexpected negative consequences. Wireless screen sharing/mirroring in conference rooms may stop working. Accessing printers may break. Any number of other issues may creep up given broad service dependencies on mDNS.”
In other words, Microsoft’s position is simple: mDNS is really useful! Sure, it won’t make the security folks happy. But you’ll really like it! And even if we give you a switch to disable it, it doesn’t really disable it. So we won’t bother! Did we mention mDNS is really useful? Trust us, you’ll want to leave it enabled.
I get it. Flipping a switch in the operating system to “disable” mDNS would give a false sense of security. As Ulrich notes, the packets are limited to a single VLAN — they can’t route to another network. The only way to be sure is to nuke it from orbit…er, block the protocol with a host-based firewall, and luckily Windows comes with one built-in. But it does feel a bit like throwing up the white flag, instead of giving users (and admins) a 70% solution.
As older protocols are replaced by newer ones, I worry that we might see this happen more often. The days of the traditional network and perimeter-based security are long gone. Zero trust rules the day, BYOD is in, and the “Corporate” issued-and-managed laptop is turning into drop-ship-from-Dell. Users want point-and-click, it-just-works, and Alexa talking to Google talking to Siri with a dollop of ChatGPT on top. Sure, the security folks dislike it, but they need to stop living in the 1990s. We’re proudly standing on your lawn with our smartphones and Bluetooth earbuds — it’s called 5G and I like streaming my Netflix in 4K while I approve payroll, and yes, I can do both simultaneously because I have a folding smartphone.
This decision to not officially provide support for turning off what’s clearly an optional component of the operating system shouldn’t come as a surprise — think telemetry and Cortana in previous editions of Windows. But the abuse factor of those components was limited or nonexistent. There’s more at risk with mDNS, as shown by the Apple patch, and Microsoft admits there is at least one scenario — “a high security requirement” — where blocking mDNS traffic is recommended. But Microsoft has set forth their position, and they are effectively giving up on mDNS security, because the computing world has changed.
Whether you agree with it or not, one thing is certain: packet captures are going to get a lot bigger. Work on your Wireshark filter fu.