The recent patch to iOS/macOS for CVE-2023-42846 made me think it is probably time to write up a reminder about the privacy impact of UPNP and multicast DNS. This is not a new issue, but it appears to have been forgotten a bit [vuln]. In particular, Apple devices are well-known for their verbose multicast DNS messages.
What is multicast DNS?
Typically, we think of DNS as a client-server protocol where our clients will connect to preconfigured resolvers. In this scenario, it is possible to register hostnames dynamically. Still, the setup is complex and requires configuring the DNS server to allow for these registrations. For a home user, this is complex, but you would still like to have the option to refer to systems by hostname instead of by IP address.
Multicast DNS solves two issues: It allows hosts to register their name and any services they offer and allows hosts connected to the same local network to find services offered by hosts on the network. Multicast DNS uses port 5353 and the multicast group 224.0.0.251 (IPv4) or ff02::fb (IPv6). These are link-local addresses, and the traffic is not routable. The main security feature of Multicast DNS is that the messages only reach local hosts on a (believed to be) trusted local network. There is no authentication or encryption of the messages as this would require some cryptographic key infrastructure. The protocol is supposed to be "plug and play."
Netbios and LLMNR have played roles like this in Windows, but even Windows has been moving to mDNS. While mDNS was originally developed by Apple as "Bonjour", it has now been adopted by Windows and Linux. Another similar protocol is SSDP (Simple Service Discovery Protocol). SSDP is often used next to mDNS. But SSDP never became an IETF standard, and no RFC describes it. Instead, the SSDP standard is now defined as part of Universal Plug and Play (UPNP) [upnp]
In my opinion, the largest risk from mDNS comes from users joining untrusted networks (think the classic example of a coffee shop or SANS event WiFi network). Their devices will "broadcast" (I should say "multicast") details to everybody on the network willing to listen.
Operating systems come with mDNS resolvers, but disabling them may not solve the problem entirely. Instead, blocking port 5353 outbound and inbound is usually recommended on host-based firewalls [msft].
But let's look at a quick example to see what information is being sent as part of mDNS messages:
2019 MacBook Pro._device-info._tcp.local: type TXT, class IN
Name: 2019 MacBook Pro._device-info._tcp.local
Type: TXT (Text strings) (16)
.000 0000 0000 0001=Class: IN (0x0001)
0... .... .... ....=Cache flush: False
Time to live: 4500 (1 hour, 15 minutes)
Data length: 51
TXT Length: 20
TXT: model=MacBookPro15,2
TXT Length: 10
TXT: osxvers=23
TXT Length: 18
TXT: ecolor=157,157,160
First of all you will see the hostname. By default, this usually includes the name of the primary user of the device. I renamed it to "2019 MacBook Pro". Interesting are also the model: MacBookPro15,2, which is the model number of a 2019 MacBook Pro, and for some reason, apple thinks it is a good idea to send along the color of the devices. 157,157,160 are the RGB codes for the silver color of the MacBook.
Disabling mDNS in a home network is usually a bad idea. It will break many convenient features like finding shared disks, using screen sharing, and printing. For iOS, in particular, I am aware of no great way to disable mDNS. If you know one, Let me know. At the very least, you want to "anonymize" the hostname. Call your iPhone "iPhone" instead of "Johannes' iPhone." And use cellular connectivity instead of public WiFi if possible.
Home automation systems, smart speakers, network-connected TVs, and audio receivers also use mDNS to discover each other. IoT devices often use mDNS to make it easier to configure and discover them. This can also lead to issues if you are trying to keep these devices on a different VLAN. The multicast messages will not leave the VLAN, which may lead to difficulties using these devices.
[vuln] https://www.youtube.com/watch?v=T3XABxNogTA
[upnp] https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf
[msft] https://techcommunity.microsoft.com/t5/networking-blog/mdns-in-the-enterprise/ba-p/3275777
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
No comments:
Post a Comment