92 lines
5.8 KiB
Markdown
92 lines
5.8 KiB
Markdown
# 5353/UDP Multicast DNS (mDNS) and DNS-SD
|
||
|
||
## 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:
|
||
|
||
 (1) (1).png>)
|
||
|
||
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
|
||
|
||
```bash
|
||
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**](https://github.com/aatlasis/Pholus/) to send a mDNS requests (-rq) on the local network and capture multicast mDNS traffic (for -stimeout 10 seconds):
|
||
|
||
```bash
|
||
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**:
|
||
|
||
```bash
|
||
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="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](pentesting-network/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](https://books.google.co.uk/books/about/Practical\_IoT\_Hacking.html?id=GbYEEAAAQBAJ\&redir\_esc=y)
|