9.0 KiB

Raw Permalink Blame History

5353/UDP Multicast DNS (mDNS) and DNS-SD

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access to the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!
Discover The PEASS Family, our collection of exclusive NFTs
Get the official PEASS & HackTricks swag
Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦@carlospolopm.
Share your hacking tricks by submitting PRs to the hacktricks repo and hacktricks-cloud repo.

Basic Information

Multicast DNS (mDNS) is a zero-configuration protocol that lets you perform DNS-like operations on the local network in the absence of a conventional, unicast DNS server. The protocol uses the same API, packet formats, and operating semantics as DNS, allowing you to resolve domain names on the local network. DNS Service Discovery (DNS-SD) is a protocol that allows clients to discover a list of named instances of services (such as test._ipps._tcp.local, or linux._ssh._tcp.local) in a domain using standard DNS queries. DNS-SD is most often used in conjunction with mDNS but isn’t dependent on it. They’re both used by many IoT devices, such as network printers, Apple TVs, Google Chromecast, Network-Attached Storage (NAS) devices, and cameras.
Default port: 5353/UDP

PORT     STATE SERVICE
5353/udp open  zeroconf

How mDNS Works

Devices use mDNS when the local network lacks a conventional unicast DNS server. To resolve a domain name for a local address using mDNS, the device sends a DNS query for a domain name ending with .local to the multicast address 224.0.0.251 (for IPv4) or FF02::FB (for IPv6). You can also use mDNS to resolve global domain names (non .local ones), but mDNS implementations are supposed to disable this behavior by default. mDNS requests and responses use UDP and port 5353 as both the source and destination port.

The mDNS replies contain several important flags, including a Time-to- Live (TTL) value that signifies how many seconds the record is valid. Sending a reply with TTL=0 means that the corresponding record should be cleared. Another important flag is the QU bit, which denotes whether or not the query is a unicast query. If the QU bit isn’t set, the packet is a multicast query (QM). Because it’s possible to receive unicast queries outside of the local link, secure mDNS implementations should always check that the source address in the packet matches the local subnet address range.

How DNS-SD Works

DNS-SD allows clients to discover available services on the network. To use it, clients send standard DNS queries for pointer records (PTR), which map the type of service to a list of names of specific instances of that type of service.

To request a PTR record, clients use the name form "<Service>.<Domain>". The <Service> part the service name preceded by "_" (for example, _ipps, _printer, or _ipp) and either _tcp or _udp. The <Domain> portion is ".local".
Responders then return the PTR records that point to the accompanying service (SRV) and text (TXT) records. Here is an example of a PTR record:

  _ipps._tcp.local: type PTR, class IN, test._ipps._tcp.local

The part of the PTR record to the left of the colon is its name, and the part on the right is the SRV record to which the PTR record points. The SRV record lists the target host and port where the service instance can be reached. For example, the next image shows a "test._ipps._tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:

Therefore, the name of the SRV record is like the PTR record preceded by the <Instance> name (test in this case). The TXT has the same name as the SRV record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.

Enumeration

nmap

nmap -Pn -sUC -p5353 192.168.1.2

Starting Nmap 6.46 (http://nmap.org) at 2015-01-01 10:30 GMT
Nmap scan report for 192.168.1.2
PORT     STATE SERVICE
5353/udp open  zeroconf
| dns-service-discovery:
|   9/tcp workstation
|     Address=192.168.1.2
|   22/tcp ssh
|     Address=192.168.1.2
|   22/tcp sftp-ssh
|     Address=192.168.1.2
|   445/tcp smb
|     Address=192.168.1.2

Network Enumeration

You can learn a lot about the local network by simply sending mDNS requests and capturing multicast mDNS traffic.

You can use the tool Pholus to send a mDNS requests (-rq) on the local network and capture multicast mDNS traffic (for -stimeout 10 seconds):

sudo python3 pholus3.py eth0 -rq -stimeout 10

Attacks

Abusing the mDNS Probing Phase

When a mDNS responder starts or changes its connectivity, it asks the local network if there is any resource with the name he plans to use. If the answer contains the record in question, the probing host should choose a new name. If 15 conflicts take place within 10 seconds, the host must then wait at least five seconds before any additional attempt. Additionally, if one minute passes during which the host can’t find an unused name, it reports an error to the user.

The following command line will prevent any new device to get any new name as it will indicate that any name is already taken:

sudo python pholus.py eth0 -afre -stimeout 1000

Spoofing/MitM

The most interesting attack you can perform over this service is to perform a MitM in the communication between the client and the real server. You might be able to obtain sensitive files (MitM the communication with the printer) of even credentials (Windows authentication).
For more information check:

{% content-ref url="../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md" %} spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md {% endcontent-ref %}

References

Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things