mDNS and SSDP vulnerabilities a suggestion for devices in the DMZ

[ravenstar68]

The other day I got a letter about a device on my home network responding to Multicast DNS (mDNS) queries from outside my home network.

Other people have received similar letters and also letters discussing Netbios, and SSDP vulnerabilities as well.

These letters come as a result of Virgin Media being contacted by a third party organisation -shadowserver.org  Who send queries out to peoples public facing IP's and see if they get a response back.

Why are Shadowserver doing this?

Quite simply to enable the closing down of exploits that others can use to mount DDOS attacks against internet users.

Devices in the DMZ

In several cases in the mDNS threads we see devices have been placed in the DMZ to facilitate some aspect of internet connectivity.  In several cases these have been PS4's in my own case it was a PC.  The problem is that if a device is in the DMZ - all unsolicited traffic is sent to that device - UNLESS there is a separate port forwarding rule in place.  This exposes any flaw in the way a device handles incoming SSDP and mDNS queries from the internet.

False positive?

Several people have suggested that the letters are sent out based on false positives.  Based on my own experience, I would say this is not correct.  Contacting Shadowserver, I was sent the log of what they found from my IP.  I recognised the culprit straight away as being Airserver, which allows me to stream from my Ipad to my PC.  However the logs can be confusing to the average user.

Port blocking?

Advice from Virgin Media suggests blocking inbound ports in the firewall section.  Unfortunately the Superhub 3 does not have any rules to do this, and some people advise that turning up the firewall breaks their gaming experience.  So we need to consider an alternative method.

Using Port Fowawrding to drop the inbound traffic.

Inbound traffic is evaluated in the following order.

NAT table entry - response to outbound traffic?
Port Forwarding rule
Device in DMZ

So by setting up port forwarding rules to an IP address that doesn't have anything connected we can drop the inbound traffic from the internet side of the network.

This won't affect normal LAN traffic, so devices on the same LAN can still find each other.  I've already done this with mDNS and my IPad can still happily find Airserver on my PC but Shadowserver can no longer find it.

This help article by Virgin Media describes for to Port Forward on the different Hubs

As noted above rules should be set according to the Vulnerability or you can preempt them.  And set them all up.

I currently have mDNS - Port 5353 UDP forwarded to 192.168.0.253
                         SSDP - Port 1900 UDP forwarded to 192.168.0.253

Will this stop a device connecting to the Internet?

No - these services are meant for use on the Local network only.  Devices connecting to the net use other outbound ports to do so.

Ravenstar68

Note: Windows Firewall makes it possible to limit a system to allowing inbound connections from the same LAN.  I've actually done this with Airserver and a number of other mDNS listeners.  However as this won't help people who are not using Windows devices, I feel port forwarding offers the easiest option.

[ravenstar68]

While you might know your way around your router - that does not make you an expert on networking if I may say so.

You're getting the mDNS letter because something on your network is responding to an mDNS probe from OUTSIDE your network.  These probes along with other types of probe are sent by an organisation called Shadowserver, who's aim is to encourage organisations and individuals to close down these holes.

Many of these scan types probe vulnerabilities that can be used to include your system as part of a DDOS attack against a third party without your knowledge.

Blocking Outbound mDNS is not the problem, indeed depending on how it's done, it can cause  more problems then it solves.

My solution for devices in the DMZ was to create a port forwarding rule that routes the inbound packets to a different port to 5353.  This is because mDNS ONLY listens on that port.  On the Hub 3 at least port forwarding rules are applied BEFORE the DMZ is considered.  So by doing this I was effectively forcing my PC to drop the inbound mDNS packets from outside the network (as I chose a port that the PC doesn't listen on).

However mDNS packets generated from devices inside my network still continue to reach their targets (i.e. other devices on my LAN)

Note that Shadowserver ONLY see a positive when they get an mDNS response back from a query sent to your PUBLIC IP.  Virgin Media don't monitor your outbound traffic, they respond to notifications from Shadowserver that your IP address has responded to their queries.

Tim

[gonepearshaped]

@ravenstar68. Actually I used to be a network engineer.

I do not have any DMZ set up and as mentioned I have 1 port open which is not mDNS related. Upnp also isn't enabled, and looking at the active NAT sessions there is no port 5353 open.

Using https://hackertarget.com/udp-port-scan/ you can see that the port is effectively dropped so as mentioned in my email, unless Shadowserver is intercepting outbound requests I'm not sure how they've come to the conclusion that I'm open to mDNS queries.

As per standard firewall rules, open/filtered means there's no response on that port.

Starting Nmap 7.40 ( https://nmap.org ) at 2018-12-19 09:40 UTC
Nmap scan report for X.X.X.X
Host is up.
PORT      STATE         SERVICE
53/udp    open|filtered domain
69/udp    open|filtered tftp
123/udp   open|filtered ntp
161/udp   open|filtered snmp
1900/udp  open|filtered upnp
5353/udp  open|filtered zeroconf
11211/udp open|filtered memcache

k

[ravenstar68]

Well my suggestion at this point would be to ask Shadowserver if they can provide you with the mDNS response string seen, as well as ask them to check directly if they can still see mDNS responses from your public IP.  That way you cut out the middleman as it were.

Certainly, when I asked them for the information, they did provide it.

Details on Shadowserver's mDNS project can be found here, including how to contact them.

https://mdns.shadowserver.org/

TIm

Edit 5353 shouldn't show in an active NAT session, while the mDNS RFC DOES allow for responses from remote IP addresses, in practice all transactions should only really be on the local network and not cross the LAN/WAN boundary.

[cwatty]

Have received four letters from Virgin Media this year so far about this issue. Again like everyone else its because I have a PS4 in the DMZ on my Asus RT-N66U Router that I use as well frankly the Super Hub 2 I have is woeful so it's best left running only in Modem Mode.

Have tried to create a Port Forward Rule in the Asus Router Configuration for the PS4 and routing the Port 5353 stuff to a non-existent device on the network with IP Address 192.168.1.253. I've also gone into the Firewall Section of the Router and under the Network Services Filter created a Black List rule that the PS4 can't communicate with any IP Address on LAN or WAN on Port 5353 and ensured that Rule is in force 24/7

Yet I still keep receiving these letters. Not sure what else to do in my Router settings to stop this.

[ravenstar68]

I don't work for VM - but would you be willing to let me have your public IP address so I can see what an mDNS query returns?

I'll understand if you don't wish to do this.  If you do however drop me a PM and I'll have a look.  It might not be til later tonight or tomorrow though.

Tim

Edit - Don't post your IP on the open forums, and do consider carefully before accepting my offer.  While I know I am trustworthy, you'll have to decide whether or not you feel comfortable sharing.

[cwatty]

I've done a scanner via the hackertarget website and the result comes back:

PORT STATE SERVICE
53/udp closed domain
69/udp closed tftp
123/udp closed ntp
161/udp closed snmp
1900/udp open|filtered upnp
5353/udp open zeroconf
11211/udp closed memcache

Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds

So despite my best efforts so far my Asus RT-N66U Router is still allowing access on that port.

[Vince68]

Hi

I have had a similar issue in the past which, apparently, was caused by the PS4 in the DMZ and resolved it by forwarding port 5353 to a high port 65535 on the Hub.

A year ago I enabled the superhub3 as modem only and used a Netgear router (first R7000 and then replaced currently with R8000) as my router due to the Hub port forwarding being not great when it came to an app I needed to use to remote control my PS4.

I was able to setup the R7000 with the same port forwarding rules of the hub and I believe I avoided triggering any MDNS vulnerability.

Since I replaced the R7000 with the R8000 I have been unable to forward port 5353 to a higher port as there is a conflict on that port and I have not been able to understand what is causing the conflict (I disabled uPnP but it made no difference). 

I recently got an email from VM about MDNS vulernability with a date and my IP address and nothing else.  

I suspect the culprit could still be the PS4 on the DMZ however I cannot be sure as so many things have changed in the last year in terms of my networking setup, program installed, etc.

I have emailed shadow server as I am hoping that they can identify the culprit but, from what I read in this forum, their reports can be tricky to read (assuming they will send me one).

So, as first action I removed the PS4 from the DMZ hoping it will stop any more emails from VM however, I do not want to just forward ports without understanding what has caused the vulnerability (although I suspect it is a device in the DMZ). Also, there is the added issue that I cannot port forward 5353 due to a conflict which I am unable to solve.

Any help would be appreciated.

[jem101]

There's a couple of potential answers here, the issue all seems to be due to having a device (PS4) in the DMZ. Now @ravenstar68 solution right at the start of this thread works perfectly but was for the VM Hub 3 which is behaving as we might expect a firewall to, ie we have a rule specifying that inbound traffic on port UDP 5353 is to be allowed in, the port translated to to something higher and forwarded to a non-existent host. Since the host doesn't respond the Hub simply drops the packet.

All well and good.

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.

Either one of these possibilities would explain why ravenstar68's solution does not appear to be working for some users with the Hub in modem mode.

To be honest, I have never really liked the 'DMZ' implementation in domestic routers on the grounds that you really can't be sure what it is doing. Personally I think it would be much better to find out exactly what ports are required to be open for the PS4 to work, take it out the DMZ and create a set of explicit  forwarding rules to it directly. As I understand it the VM Hub 3 has a few 'quirks' shall the say (being kind to it) about forwarding rules but then the DMZ trick works OK for it, and third-party routers tend to be much better at this sort of stuff anyway.   

[用心棒]

---

@Vince68 wrote:

⋮
I have had a similar issue in the past which, apparently, was caused by the PS4 in the DMZ and resolved it by forwarding port 5353 to a high port 65535 on the Hub.

⋮

The solution proposed was to forward port 5353 to an unallocated IP address within your LAN, is that what you have done?

[用心棒]

---

@jem101 wrote:
⋮

However we can't really assume that third party routers behave in the same manner - for example the help page for the Asus RT-66 under DMZ, if you take their description at face value, seems to be saying that it forwards ALL unsolicited inbound traffic to the device which you specify as being in the DMZ. Now it could just be poorly worded, but it does sound that if you have a device in the DMZ, the Asus is simply going to ignore the port forward rules and simply forward everything there. It may be that other third-party routers do the same. Another possibility is that if a rule tries to forward traffic to an unresponsive host, then rather than dropping the packets, it forwards them to the DMZ device instead.
⋮ 

---

More likely poor (simplistic) wording; consumer routers probably implement the DMZ as a (terminating) port forward rule.