Homeland Security: Disable UPnP, as tens of millions at risk

stephenw10

In the actual release by Rapid7 the refer to flaws in both libupnp and miniupnp:
@https://community.rapid7.com/community/infosec/blog/2013/01/29/security-flaws-in-universal-plug-and-play-unplug-dont-play:

The flaws identified in the MiniUPnP software were fixed over two years ago, yet over 330 products are still using older versions.

…...

332 products use MiniUPnPd version 1.0, which is remotely exploitable. Over 69% of all MiniUPnPd fingerprints were version 1.0 or older

Hence pfSense, which is using a much more recent release of miniupnp, is not affected.

Steve

Edit: I should probably read the whole thing but TLDR! Is there a list of those 332 products?

matguy

Just to put this in the proper perspective:

A service that's made to make devices connectable from outside sources is vulnerable to being connected to from outside sources and compromised. To say it a different way, a service that makes it easy to bypass the role of the firewall has a vulnerability in itself, which is a big deal since it's not being blocked by the firewall.

cmb

@dhatz:

I am a bit confused with cmb's blog post …

pfSense is using miniupnp http://miniupnp.free.fr/

The vulnerability mentioned in the first post was identified in libupnp, and US CERT recommends upgrade to libupnp v1.6.18, which was only released yesterday http://sourceforge.net/projects/pupnp/files/pupnp/

What am I missing?

libupnp has no relation to miniupnp. miniupnp fixed 2+ years ago all the issues that were found, libupnp just fixed yesterday.

LinuxTracker

DHS is saying that a service that doesn't listen to requests on the WAN adapter, is directly exploitable through the cloud.

Do I have that right? I ask because it doesn't make sense to me.

stephenw10

Nope. As I read it…

Over 80 million unique IPs were identified that responded to UPnP discovery requests from the internet

So that's listening on their WAN side. And…

Somewhere between 40 and 50 million IPs are vulnerable to at least one of three attacks outlined in this paper

Although it shouldn't be possible to do anything from an external IP because of flaws in the code providing upnp it is. Not only that but it appears the flaws are not limited to allowing external devices to open firewall holes, use the upnp service, but can allow more extreme exploits like random code execution. E.g.
http://hackaday.com/2013/01/31/turning-the-belkin-wemo-into-a-deathtrap/

Steve

LinuxTracker

I'm on a residential dhcp cable connection.
A quick scan of my /24 turned up this gem.

nmap -sT -sU -p 1900,2864 --script upnp-info.nse 68.xxx.xx.0/24

1900/udp open  upnp
| upnp-info: 
| 68.xxx.xx.xxx
|     Server: Microsoft-WinCE/5.0 UPnP/1.0 UPnP-Device-Host/1.0
|     Location: http://68.xxx.xx.xxx:5120/upnp/41414241-4a46-5047-4e42-4f4a00000000.xml
|       Webserver: Microsoft-WinCE/5.0
|       Name: MSN TV 2 Internet and Media Player : msntv-001095f6d1e9
|       Manufacturer: RCA
|       Model Descr: MSN TV 2 Internet and Media Player
|       Model Name: RM4100
|_      Model Version: RM4100

This looks like a device that isn't properly firewalled.

However, a number of other IPs in my /24 showed this.

1900/tcp filtered      upnp
2864/tcp filtered      unknown
1900/udp open|filtered upnp
2864/udp open|filtered astromed-main

Interestingly, my IP is one that shows open.
nmap seems to indicate that I (and other IPs in my /24) have 1900/2864 UDP open w/ no services.

But this external UPNP checker says:

Congratulations! Your router did not respond to a UPnP discovery request.

http://upnp-check.rapid7.com/

So I'm not sure what to make of it.
Maybe I'm misunderstanding the nmap results - also - scanning my own IP is problematic.

Note:
My cable modem is de-bridged so my pfSense box directly connects w/ cloud.

matguy

Well, define "my /24". Do you mean the /24 private IP space behind your firewall where your devices are, which sounds likely considering the context. Or do you mean a /24 that you and your neighborhood are serviced with by your ISP?

I got it now, yes, the local ISP's subnet that you and your neighbors happen to be on. Had to tune my context detection ;)

It could be difficult for the scanning application to effecively scan your external IP address from inside your network behind your pfSense firewall running NAT, the old "can't go out the router and back in" scenario. Sometimes it works, depending on a lot of factors, but I certainly wouldn't expect a port scan to work.

matguy

Btw, I just downloaded and tried to run the ScanNowUPNP app. It requires Java… I'm sure someone will catch the irony.

(BTW, I ran it in a VM, since I didn't exactly trust the software that I don't know, but now I see it's the same people that do MetaSploit, I'm not sure if that makes me feel better or not.)

But my internal network came back with zero expoitable or identified. Which is interesting since there's Tivo, Wii, a number of "appliance" applications, etc. I would have imagined that something was UPNP-able.

Edit: Added description for what network I was scanning.

stephenw10

Those things are likely to contain upnp client software but not a upnp daemon that would be listening on port 1900.

Steve

cmb

@matguy:

Btw, I just downloaded and tried to run the ScanNowUPNP app. It requires Java… I'm sure someone will catch the irony.

First thing I noticed… gotta be kidding me, a security tool requires Java to be installed? I keep that crap off my systems aside from one VM for a reason! ;D

cmb

@LinuxTracker:

Interestingly, my IP is one that shows open.
nmap seems to indicate that I (and other IPs in my /24) have 1900/2864 UDP open w/ no services.

Just a misunderstanding of port scanning UDP. With UDP, either you get an ICMP unreachable, so the port is closed, or you get no response at all, which either means the port is open or it's filtered by a firewall. That's what "open|filtered" means in nmap. Not very helpful, but there is no difference in response between an open UDP port and one that a firewall is silently blocking.

Tools that actually send a UPnP request and will check for responses will be able to determine whether it's open or filtered. A UDP port scan can't differentiate between those.