hacktricks/network-services-pentesting/5353-udp-multicast-dns-mdns.md

## Informações Básicas

Multicast DNS (mDNS) é um **protocolo de configuração zero** que permite realizar **operações semelhantes ao DNS** na rede local na ausência de um servidor DNS convencional unicast. O protocolo usa a **mesma** API, **formatos de pacote** e semântica de operação que o DNS, permitindo resolver nomes de domínio na rede local. **DNS Service Discovery (DNS-SD)** é um protocolo que permite aos clientes **descobrir uma lista de instâncias nomeadas de serviços** (como test.\_ipps.\_tcp.local, ou linux.\_ssh.\_tcp.local) em um domínio usando consultas DNS padrão. O DNS-SD é mais frequentemente usado em conjunto com o mDNS, mas não depende dele. Ambos são usados por muitos dispositivos IoT, como impressoras de rede, Apple TVs, Google Chromecast, dispositivos de armazenamento conectados à rede (NAS) e câmeras.\
**Porta padrão:** 5353/UDP
```
PORT     STATE SERVICE
5353/udp open  zeroconf
```
### Como o mDNS funciona

Os dispositivos usam o mDNS quando a rede local **não possui** um **servidor DNS unicast convencional**. Para resolver um nome de domínio para um endereço local usando o mDNS, o dispositivo envia uma **consulta DNS para um nome de domínio** terminando com **.local** para o **endereço multicast** **224.0.0.251** (para IPv4) ou **FF02::FB** (para IPv6). Você também pode usar o mDNS para resolver **nomes de domínio globais** (não .local), mas as implementações do mDNS devem **desativar** esse comportamento por padrão. As solicitações e respostas do mDNS usam **UDP** e a **porta 5353** como porta de origem e destino.

As respostas do mDNS contêm várias flags importantes, incluindo um valor de **Tempo de Vida** (TTL) que significa quantos segundos o registro é válido. O envio de uma resposta com **TTL=0 significa que o registro correspondente deve ser apagado**. Outra flag importante é o bit QU, que denota se a consulta é uma consulta unicast. Se o **bit QU não estiver definido**, o pacote é uma consulta multicast (QM). Como é possível **receber consultas unicast fora do link local**, as implementações seguras do mDNS devem sempre **verificar se o endereço de origem no pacote corresponde ao intervalo de endereços da sub-rede local**.

### Como o DNS-SD funciona

O DNS-SD permite que os clientes **descubram serviços disponíveis na rede**. Para usá-lo, os clientes enviam consultas DNS padrão para registros de ponteiro (PTR), que mapeiam o tipo de serviço para uma lista de nomes de instâncias específicas desse tipo de serviço.

Para solicitar um registro PTR, os clientes usam a forma de nome "\<Serviço>.\<Domínio>". A parte **\<Serviço>** é o **nome do serviço** precedido por "\_" (por exemplo, \_ipps, \_printer ou \_ipp) e **\_tcp ou \_udp**. A parte **\<Domínio>** é "**.local**".\
Os **respondedores** retornam então os registros PTR que apontam para os registros de **serviço (SRV)** e **texto (TXT)** correspondentes. Aqui está um exemplo de um registro PTR:
```
  _ipps._tcp.local: type PTR, class IN, test._ipps._tcp.local
```
A parte do registro PTR à **esquerda** do dois pontos é o seu **nome**, e a parte à **direita** é o registro **SRV** para o qual o registro PTR aponta. O registro **SRV** lista o **host** e a **porta** de destino onde a instância do **serviço** pode ser alcançada. Por exemplo, a próxima imagem mostra um registro SRV "test.\_ipps.\_tcp.local" no Wireshark no host ubuntu.local e na porta 8000:

![](<../.gitbook/assets/image (651) (1) (1) (1) (1).png>)

Portanto, o **nome do registro SRV** é **semelhante** ao registro **PTR** **precedido** pelo nome da **\<Instância>** (test neste caso). O **TXT** tem o **mesmo nome** que o registro **SRV** e contém as informações necessárias quando o endereço IP e o número da porta (contidos no registro SRV) para um serviço não são suficientes para identificá-lo.

## Enumeração

### 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
```
### Enumeração de Rede

Você pode aprender muito sobre a rede local simplesmente enviando solicitações mDNS e capturando tráfego mDNS multicast.

Você pode usar a ferramenta [**Pholus**](https://github.com/aatlasis/Pholus/) para enviar solicitações mDNS (-rq) na rede local e capturar tráfego mDNS multicast (por -stimeout 10 segundos):
```bash
sudo python3 pholus3.py eth0 -rq -stimeout 10
```
## Ataques

### Abusando da Fase de Probing do mDNS

Quando um respondedor mDNS inicia ou altera sua conectividade, ele pergunta à rede local se há **qualquer recurso com o nome que ele planeja usar**. Se a resposta contiver o registro em questão, o host de probing **deve escolher um novo nome**. Se 15 conflitos ocorrerem dentro de 10 segundos, o host deve esperar pelo menos cinco segundos antes de qualquer tentativa adicional. Além disso, se um minuto passar durante o qual o host não conseguir encontrar um nome não utilizado, ele reportará um erro ao usuário.

O seguinte comando de linha de comando impedirá que qualquer novo dispositivo obtenha um novo nome, pois indicará que **qualquer nome já está sendo usado**:
```bash
sudo python pholus.py eth0 -afre -stimeout 1000
```
### Spoofing/MitM

O ataque mais interessante que você pode realizar neste serviço é realizar um **MitM** na **comunicação entre o cliente e o servidor real**. Você pode ser capaz de obter arquivos sensíveis (MitM a comunicação com a impressora) ou até mesmo credenciais (autenticação do Windows).\
Para mais informações, consulte:

{% 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](../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
{% endcontent-ref %}

## Referências

* [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)

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!

- Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)

- Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)

- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me no** **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**

- **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.

</details>