To view other posts in this mini series, select the tag “Cleaning Up Risky Traffic, A Mini Series”

Cleaning Up Risky Traffic, A Mini Series: mDNS

Multicast DNS (mDNS) is a protocol that allows devices on a local network to discover and communicate with each other using domain names instead of IP addresses. mDNS is used in many modern devices such as smartphones, smart TVs, and printers to simplify network configuration and improve user experience. However, mDNS can also pose a security risk if not properly configured.

In this article we will review what mDNS is, what controls can be implemented to prevent compromise, a list of MITRE Tactics and CVE’s associated with mDNS, and we’ll set up a honeypot to detect for this attack vector.

mDNS works by allowing devices to respond to queries for domain names on the local network. When a device needs to find another device, it sends out a multicast DNS query containing the domain name of the device it is looking for. All devices on the local network receive the query and any device that matches the domain name replies with its IP address.

This can be exploited by attackers who can send fake responses to the query, tricking the device into communicating with a malicious device instead. This type of attack is known as an mDNS poisoning attack.

However, mDNS can be exploited by attackers to compromise a system in a number of ways, such as:

1. Name Spoofing: An attacker can spoof the domain name of a legitimate device to trick users into connecting to a malicious device instead. This can be used to steal sensitive information or to launch further attacks. MITRE Tactic: Deception (T1140) MITRE Link: https://attack.mitre.org/tactics/TA1140/
2. Man-in-the-middle (MITM) attacks: Attackers can use mDNS to carry out MITM attacks by spoofing the domain name of a legitimate device and intercepting the traffic between the two devices. MITRE Tactic: Man-in-the-middle (T1557) MITRE Link: https://attack.mitre.org/tactics/TA1557/
3. Denial of Service (DoS) attacks: mDNS can be used to launch DoS attacks by flooding a system with a large number of mDNS requests, causing the system to become unresponsive or crash. MITRE Tactic: Resource Exhaustion (T1499) MITRE Link: https://attack.mitre.org/tactics/TA1499/
4. Information Gathering: mDNS can also be used to gather information about a target system, such as its domain name, IP address, and MAC address. This information can be used to launch further attacks against the system. MITRE Tactic: Reconnaissance (T1592) MITRE Link: https://attack.mitre.org/tactics/TA1592/

To protect against mDNS-related attacks, it is important to properly configure mDNS on devices and implement network segmentation and access control to limit the exposure of critical systems to potential attacks. Additionally, using modern authentication and encryption protocols such as DNSSEC and TLS can help to mitigate the risks associated with mDNS.

mDNS is commonly referred to as T1557.02 on the Mitre ATT&CK framework.

T1557.02 is a technique on the Mitre ATT&CK framework that refers to the use of mDNS poisoning and SMB relay attacks to gain initial access to a network. Additionally, there are several CVEs related to mDNS that have been discovered over the years, and it’s important for organizations to stay up to date on these vulnerabilities to ensure their networks remain secure.

Here are some CVEs (Common Vulnerabilities and Exposures) related to mDNS:

1. CVE-2014-1724 – Multiple stack-based buffer overflows in the mDNSResponder service in Apple OS X before 10.10.3 allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted packet.
2. CVE-2018-1111 – A flaw was found in the way the Linux kernel handled exceptions delivered after a stack switch operation via Mov SS or Pop SS instructions. During the stack switch operation, the processor did not deliver interrupts and exceptions, rather they are delivered once the first instruction after the stack switch is executed. An unprivileged local user could use this flaw to induce a kernel stack overflow and crash the system, or potentially escalate their privileges on the system. This flaw affects Linux kernels from 2.6.34 to 4.16. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
3. CVE-2020-25705 – A flaw was found in the way mDNS packets are sent and received in the avahi-daemon. An attacker on the network could use this flaw to craft a DNS response that would cause an infinite loop in the mDNS parsing code, causing avahi-daemon to enter a denial of service (DoS) state.

Note that this is not an exhaustive list, and there may be other CVEs related to mDNS that have not been included.

Testing and Verification

Checking if mDNS is in your environment is easy! Wireshark can be used to capture mDNS traffic and analyze it for potential vulnerabilities. It is important for organizations to regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats.

To detect mDNS traffic using Wireshark, you can use the following display filter:

udp port 5353

Once the filter is applied, you should be able to see all mDNS traffic in the captured packets. This can help you identify any potential mDNS-related issues or attacks on your network.

Mitigation Strategies

Properly configuring mDNS on devices is key to preventing mDNS-related attacks. This includes disabling mDNS on devices where it is not needed, and implementing network segmentation and access control to limit the exposure of critical systems to potential attacks. Additionally, using modern authentication and encryption protocols such as DNSSEC and TLS can help to mitigate the risks associated with mDNS.

The reg key you need is HKLM\\System\\CurrentControlSet\\Services\\Dnscache\\Parameters\\EnableMDNS

DWORD set to 0

Powershell one liner for a login script:

set-ItemProperty "HKLM:\\SYSTEM\\CurrentControlSet\\Services\\Dnscache\\Parameters\\" -Name EnableMDNS -Value 0 -Type DWord

Honeypots!

Setting up a honeypot for mDNS can help you detect and monitor any attempts to exploit mDNS-related vulnerabilities or attacks. Here is a basic honeypot setup you can use for mDNS:

1. Set up a virtual machine: You can set up a virtual machine (VM) on your network that runs a vulnerable version of a device with mDNS enabled. This VM will act as the honeypot for mDNS-related attacks.
2. Disable unnecessary services: To limit the attack surface of the honeypot, disable any unnecessary services or applications that are not required for mDNS functionality.
3. Monitor traffic: Use a network monitoring tool such as Wireshark to monitor traffic to and from the honeypot. Filter the traffic to show only mDNS traffic by using the display filter “udp port 5353”.
4. Set up alerts: Set up alerts to notify you when any mDNS-related activity is detected on the honeypot. You can use tools such as Snort or Suricata to create custom rules that trigger alerts based on specific network traffic patterns or signatures.
5. Log all activity: Log all activity on the honeypot to track any potential attacks or suspicious behavior. This can help you identify attack patterns and determine the severity of any attempted attacks.
6. Regularly review and update: Regularly review the logs and alerts generated by the honeypot to identify any new attack patterns or vulnerabilities. Use this information to update your security measures and defenses.

Note that honeypots can attract malicious actors, so it’s important to ensure that the honeypot is isolated from the rest of your network and that appropriate security measures are in place to protect your network and data.

Vulnerability Scanners and ‘Informational’ Vulnerabilities

You’ll notice on your vulnerability scanner (Nessus, Rapid7, etc.) that mDNS and many other multicast traffic controls show up as a ‘low’ or ‘informational’ vulnerability. My assumption is that it scores this as Informational because mDNS is not technically a “vulnerability” (assuming devices are patched). Meaning the software itself works as designed… There is no patch needing to be installed to make it secure.

It’s kind of like standing up an FTP server and allowing anonymous logins with full access. It’s a bad idea, but I wouldn’t expect a vulnerability scanner to scream about it unless you are running an FTP server with a known vulnerability.

In a vendor-centric world, a real internal conversation to be had at most orgs is about not hinging one’s security practices squarely on compliance requirements and/or “best practices” (present company included). Don’t count on 3rd party tools to make you secure. If they did, then we wouldn’t see breaches every week. I just recently learned more about maturity models, which are models that scan across multiple secure frameworks (NIST, PCI, GDPR, HIPAA and more) to look for overlapping controls that actually make a difference. check out SCF — Secure Controls Framework.

https://securecontrolsframework.com/

https://securecontrolsframework.com/capability-maturity-model/

Conclusion

In conclusion, mDNS is a protocol that allows devices on a local network to discover and communicate with each other using domain names instead of IP addresses. By properly configuring mDNS on devices, utilizing alternative protocols such as DNS, and implementing network segmentation and endpoint detection and response, organizations can help to protect their networks and sensitive information. It is important for organizations to regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats.

For more information about this security control, feel free to reach out to blog@tridentstack.com. For professional services around this configuration, professionalservices@tridentstack.com, and lastly, for a full service SIEM/SOC/SOAR tool we highly recommend you check out our home page: https://tridentstack.com