Hunting for mDNS Vulnerabilities
Scanning with Nessus and Applying Proposed Solutions
I decided to run Nessus on my Windows 10 PC. This is my fastest PC. It is also my most valuable, so I want to ensure that the security is airtight (without going to extream measures). I loaded up Nessus in order to analyze the machine and the software identified 2 medium level vulnerabilities.
SMB Signing Disabled
mDNS Detection (Remote Network)
I followed the instructions in Nessus’ SMB Signing article and blocked UDP port 5353 in Windows firewall. If you are not familliar with the firewall rule creation process, Microsoft wrote better instructions than I ever could have.
Block Port With Windows 10 Firewall
Reaserching mDNS
Ran the scan again and…. the mDNS article did not vanish as expected. I went to Window’s local group policy editor and ran the scan again. No difference. I started looking into what mDNS actually was. According to RFC-6762, mDNS (Multicast DNS) essentially makes it easier for devices to communicate over a network without the end user having to get too involved in the process. It’s the reason why your iTunes can talk to other computer’s iTunes so seamlessly. Although I own an iPhone, I don’t really get too involved in the “Apple process,” so I figured why not disable it. Thankfully iTunes itself uses something called Bonjour in order to utilize mDNS.
Locking Down Everything Apple
Thankfully Bonjour can just disable it on startup right? That was the theory in my head, but it didn’t work. Although I can confirm Bonjour was no longer running via Task Manager. After looking into this, even more, it turns out Apple wasn’t the only service that used this. I went as far as to uninstall Bonjour entirely and disable all apple related services on startup. Still no luck.
Disable Link Local Multicast Name Resolution
Just for fun, I disabled the LLMNR entirely in the Group Policy editor.
Computer Configuration\Administrative Templates\Network\DNS Client\Turn off Multicast Name Resolution = Enabled
No luck. Worth a try.
Using Nessus Deep Scan Data
At this point, the problem required a Nessus deep scan. The detailed reports weren’t specific. In fact, it listed that mDNS was broadcasting from another port entirely. In fact, in the mess of numbers, one word stood out to me. The word “nvstream_dbd.”
Poking at Nvidia drivers and services
After tossing that term into Google, Forum users stated that nvStream was a process for Nvidia’s “streaming” service. I remembered that I had ShadowPlay enabled because I sometimes record myself when I do 3D modeling.
I simply disabled it and even blocked port 5353 as well as the other port on both TCP and UDP in the Windows firewall. Still no luck. At this point, things weren’t making a whole lot of sense. I began re-installing the GeForce drivers in hopes that would resolve the issue. Unfortunately, it did not. Nvidia is a very respectable company and I figured that there had to be a solution to this problem that didn’t involve me simply not using Nvidia products. Other than enabling Shadowplay, I don’t use any of Nvidia’s features.
After taking another trip to the Window’s Add/Remove Programs menu, I revisited what Nvidia installed and what each package did. Nvidia 3D Vision sounded very essential. One of those things you “just don’t touch.” But it is always good practice for one to challenge their assumptions. After googling this, those drivers existed exclusively for a hardware product Nvidia manufactured several years ago. Specifically, their 3D glasses. It didn’t occur to me because this product did not get the same amount of spotlight 3D solutions like Occulus did.
Solution
Uninstall 3D Vision drivers and applications
Keep Bonjour disabled on startup
Reverse all the changes mentioned in the article