Homeland Security: Disable UPnP, as tens of millions at risk
-
is pfSense also harmed if only internal network "LAN" is enabled for upnp?
-
Info here:
http://blog.pfsense.org/?p=688in short, none of that applies to us as we actually keep our underlying software up to date, apparently unlike a ridiculous number of commercial vendors.
-
http://blog.pfsense.org/?p=688
Security flaws in Universal Plug
and PlayRapid7 released a paper today covering
new security flaws in UPnP. These
findings have lead to the US
Department of Homeland Security
recommending everyone disable UPnP.
These flaws aren’t applicable to
pfSense users, as long as you’ve
stayed up to date, or at least haven’t
gone out of your way to make yourself
insecure. The flaws identified in
miniupnp were fixed over two years
ago, and we always ship releases with
the latest version. -
'Everyone should disable upnp' vs 'call of duty'.
I know which side I'd bet on. :P
Of the 40 million devices, how many do you think have admins (at all?) who know what upnp is let alone how to disable it? Of those how many will turn it back on when they find it causes problems with some vital service like PSN, Xbox live, Skype etc.
This is a big problem.
If you're lucky your router may still be current, have actively developed firmware and be set to auto update. What percentage do you think that is? ::)Steve
-
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?
-
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?
-
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.
-
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.
-
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.
-
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
-
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: RM4100This 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-mainInterestingly, 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. -
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.
-
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.
-
Those things are likely to contain upnp client software but not a upnp daemon that would be listening on port 1900.
Steve
-
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
-
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.
