The content of the article
Multicast DNS (mDNS) and Service Discovery (DNS-SD) are ubiquitous protocols, they are now by default included in many technical products, especially designed for a home or small office network. They are part of Zeroconf – A technology package that helps network devices find each other automatically. When you send a document for printing, and your computer itself offers the choice of the nearest printers – most likely, it uses Zeroconf. In this article I will analyze what a Pentester should know about mDNS and DNS-SD and how you can use these technologies for your own purposes.
What is mDNS?
Official sites Multicast dns and DNS Service Discovery able to confuse rather than shed light on the essence of these technologies. Therefore, before diving into the security issues of mDNS and DNS-SD, we will discuss why these protocols exist in general and what they actually do.
Both protocols are related to DNS, so here you need to at least at a basic level understand how the system works DNS. Usually, DNS works “unicast” – this means that each request is sent to a specific IP address. The word multicast (that is, "multicast") in mDNS means that the request is fan-sent to all devices of the broadcast domain (broadcast domain). The term "in itselfbroadcast domain"Means, roughly speaking, all communicating devices of the second level – for example, computers connected by network switches. This is an important point, because mDNS requests do not pass through routers – because routers are already third-level devices.
Let's look at an example. My MacBook Pro has an mDNS name
MehBook.local. You can find this out in the “Sharing” tab of the system settings.
To calculate the MacBook IP, we can use a DNS query tool like
$ dig @22.214.171.124 -p 5353 +short MehBook.local
Please note that the name ends in
.local Is a top-level domain reserved specifically for mDNS. If you see a similar name, you will probably be able to calculate IP using mDNS. Such domain names are called link-local names, because you can only see them inside the local network.
Keep in mind: some system administrators incorrectly use the local top-level domain along with unicast DNS. Watch yourself, be careful!
Instead of sending a request to the DNS server on port 53, we use port 5353 and a special address
126.96.36.199 – in fact, multicast. This particular address is reserved specifically for mDNS. When to the address
188.8.131.52 a request arrives, all network devices receive a copy of this request and can answer it. In our example, my macbook saw a request and returned my own IP address on it –
My macbook's IP is dynamic, after some time it will change – but the mDNS name will remain the same! So that we can interact with domain names without starting a DNS server. You understand how it is useful in home and small office networks.
What is DNS-SD?
In the mDNS example, we found out the IP address of a device with an already known name. But what if you want to contact a device whose name you do not know – for example, with a printer? This problem is exactly what the Service Discovery protocol solves. It allows devices to announce the specific services they offer, so that they can be discovered without a central configuration.
Let's start by calculating printers:
$ dig @184.108.40.206 -p 5353 -t ptr +short _printer._tcp.local
Brother 032DCP-L2540DW 032series._printer._tcp.local.
Here the same multicast DNS address and port will help us, but this time we request PRT records and use a special domain name
_printer._tcp.local – It is just designed to recognize printers. In response to this request, my Brother printer returned its local domain name.
If you want to request devices with other services, then you should check with them official registry. For example, there is a curious RAOP service – it is also the Apple protocol, known as AirTunes. Let's calculate it:
$ dig @220.127.116.11 -p 5353 -t ptr +short _raop._tcp.localC8D083XXXXXX@Living 32Room._raop._tcp.local
The request shows a device on my network that offers the RAOP service – this is an Apple TV called the Living Room. There are actually two Apple TVs on my network, but
dig only displays the first response received. Fortunately, there are better tools. On macOS, this is a command
dns-sd in the Rendezvous (Bonjour) software module, the Apple implementation of Zeroconf.
$ dns-sd -B _raop._tcp
Browsing for _raop._tcp
DATE: — Sun 16 Sep 2018 —
10: 02: 18.236 … STARTING …
Timestamp Domain Service Type Instance Name
10: 02: 18.237 local. _raop._tcp. D0D2B0XXXXXX @ Bedroom
10: 02: 18.238 local. _raop._tcp. C8D083XXXXXX @ Living Room
This command will send out the request and display all the answers received (to get rid of them, you will need to press Ctrl-C). Now we see both of my Apple TVs.
On Linux, the Avahi package offers the same toolkit (on Debian / Ubuntu, it's called
$ avahi-browse _raop._tcp
+ IPv6 D0D2B0XXXXXX @ Bedroom AirTunes Remote Audio local
+ IPv6 C8D083XXXXXX @ Living Room AirTunes Remote Audio local
+ IPv4 D0D2B0XXXXXX @ Bedroom AirTunes Remote Audio local
+ IPv4 C8D083XXXXXX @ Living Room AirTunes Remote Audio local
Avahi can translate service names like
_raop._tcp.local in more understandable –
AirTunes Remote Audio local, eg. Avahi can also calculate IP using mDNS, so
dig not needed here at all:
$ avahi-resolve --name Bedroom.localBedroom.local 10.105.0.230
Please note that when mDNS request we do not insert values of type
_raop._tcp – because this is the name of the service, not the device. Also we do not write anything to the left of the character
Now you can see why the Zeroconf package is interesting for pentesters: thanks to it, you can quickly find a whole list of available devices in just a couple of queries. And Avahi also allows you to automate this process. For example, it is quite realistic to pack service discovery and IP punching through mDNS in one step.
$ avahi-browse --resolve _printer._tcp
+ enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
= enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
hostname = (brotherB85F3190.local)
address = (10.105.0.3)
port = (515)
txt = ("UUID = e3248000-XXXX-XXXX-XXXX-XXXXXXXXXXXXX"
"TBCP = F" http://xakep.ru/ "Transparent = T" http://xakep.ru/ "Binary = T" http://xakep.ru/ "PaperCustom = T"
"Scan = T" http://xakep.ru/ "Fax = F" http://xakep.ru/ "Duplex = T" http://xakep.ru/ "Copies = T" http: // xakep. com / "Color = F" …)
As a result, we get the local host name, IP address and port (
tcp/515 – default port for Line Printer Daemon). Plus a lot of information about printer features in the box
The command used here is a great way to recount all devices of a particular type, however Avahi can do more! The following command computes all types of services at a time.
$ avahi-browse --all
+ IPv6 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv6 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv4 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv4 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv6 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv6 276A1455BC533567B08XXXX _appletv-v2._tcp local
+ IPv4 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv4 276A1455BC533567B08XXXX _appletv-v2._tcp local
Finally, Avahi can listen to Zeroconf protocol requests from other devices, which allows you to calculate devices in the background.
$ avahi-browse -a
+ IPv6 MehBook _companion-link._tcp local
+ IPv6 Bedroom _companion-link._tcp local
+ IPv6 Living Room _companion-link._tcp local
+ IPv4 MehBook _companion-link._tcp local
Both of these commands can be combined with
--resolveto get information about IPs and ports of each device. All network devices at a glance!
And, of course, one cannot fail to mention that
nmap supports calculating Zeroconf devices using a script broadcast-dns-service-discovery.
$ nmap --script=broadcast-dns-service-discovery
Starting Nmap 7.60 (https://nmap.org) at 2018-09-18 11:40 EDT
Stats: 0:00:03 elapsed; 0 hosts completed (0 up)
NSE Timing: About 0.00% done
Pre-scan script results:
| 80 / tcp privet
| txtvers = 1
| ty = Brother DCP-L2540DW series (ACD1B8XXXXX)
| note = Brother DCP-L2540DW series
| url = https: //www.google.com/cloudprint
| type = printer
| id = 10d70d78-XXXX-XXXX-XXXX-XXXXXXXXXXXX
| cs = online
| Address = 10.105.0.3
… snip …
This script is not included in the category.
default – it can only be found in
A bit about limitations
- This only works inside the local network, so you need to have access to it.
- Large corporate networks are usually segmented, so you need a reference point exactly within the segment you are interested in.
- There are many important services that do not make themselves known through DNS-SD – in most cases, such devices will have to be calculated differently.
- Due to the fact that these are broadcast protocols, you need to think carefully – do your tactics and strategy allow them to be used?
Okay, computing devices is fun and all, but is there anything to exploit here? We found a bunch of printers and Apple TV – and ..?
First, keep in mind that home and small office network products using Zeroconf are highly likely to have the wrong settings and vulnerabilities. One simple example: if the printer is authenticated through an LDAP server, and the default password is set by the manufacturer, you can take control of the server, force the printer to contact it and thus steal the LDAP certificate of the printer. In this way, you can quickly steal a domain account!
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru