Home => Netgear router fails to disable UPnP
|[Formatted for Printing]||From the personal web site of Michael Horowitz|
February 16, 2019
UPnP is an ancient protocol that lets devices on a network discover each other, query each other and send each other commands. It was meant to work on a Local Area Network (LAN) only and thus has no security at all. No passwords, no encryption, nothing.
As someone interested in Router Security my only interaction with UPnP is to disable it. This is because, one of the UPnP commands, is to punch a hole in the router firewall. And, this command can be issued by any device on the LAN with no notice to any humans. A hole in the firewall exposes IoT devices to the Internet at large where, if they are vulnerable, they can be hacked. IoT devices get lots of press for their poor security, but it is UPnP in a router that often enables the exploitation of the bad security.
The list of security problems associated with UPnP, both on the LAN side and the WAN/Internet side of a router, is as long as your arm. Just last month, UPnP played a role in the hacking of Chromecast devices to play PewDiePie videos. Back in 2015, the FBI issued a Public Service Announcement that warned about UPnP. Back in 2013, bugs and mis-configurations with UPnP affected millions (actually, many millions) of routers. I could go on.
So, when I recently came into possession of a Netgear Nighthawk X4 R7500 router, I turned off UPnP and went about my business.
But, an nmap scan, looking for open ports on the LAN side of the router, turned up two open TCP ports (see below) that nmap identified as UPnP. That was unexpected. Even more so that the ports were detected as running Cisco Linksys software.
nmap -sV -p 1-65500 10.8.8.8 |
PORT STATE SERVICE
49152/tcp open upnp Cisco-Linksys E4200 WAP upnpd (UPnP 1.0)
49153/tcp open upnp Cisco-Linksys E4200 WAP upnpd (UPnP 1.0)
|Interesting section of an nmap scan of the LAN side|
The Nighthawk router was running the latest firmware, version 184.108.40.206 which is from January 2019 according to the Release Notes.
To verify that UPnP was actually enabled, I ran the Android Fing app (version 8.1.3). As shown below, it found lots of UPnP information about the router. The same app looking at another router with UPnP disabled, found no UPnP information at all. Fing also runs on iOS.
I double checked this with another Android app, Network Analyzer Pro by Jiri Techet. It too, turned up lots of UPnP information about the Netgear router as you can see in the two screenshots below. Like the first app, when it analyzed another router with UPnP disabled, it found no UPnP information. And, it too runs on iOS.
Network Analyzer Pro UPnP Router info
Network Analyzer Pro UPnP Router Services
Finally, I also looked for UPnP with a Windows program, Universal Plug-and-Play Tester by Noël Danjou. The results are shown in the two screen shots below. And, like the two Android apps, this program also fails to find any UPnP data when run against another router with UPnP disabled.
|UPnP router info from Universal Plug-and-Play Tester|
So, I felt sure that the router was not actually disabling UPnP, despite what the web interface said. Fortunately, someone more expert in networking than myself suggested that I prove it. Ugh. I had never actually used UPnP. To me, UPnP was Kryptonite. I had never actually seen it in action.
It was suggested that a NAS box would use UPnP, and a Synology NAS in my home certainly did. Anyone who wants to make the files on their Synology NAS available to them when they are away from home can use the "External Access" feature to make UPnP requests to their router. The NAS can either open a specific specified port number or it will open the necessary ports for the various apps running on the NAS.
With UPnP enabled on the Netgear router, all was well. UPnP software on the NAS found the router, talked UPnP to it and commanded it to open/forward ports. I could see this three ways: while logged on to the NAS, while logged on to the router (it shows the ports that UPnP opened/forwarded) and by running nmap port queries at the WAN side of the router to confirm the ports were actually open.
But, with UPnP disabled in the Netgear router the NAS complained that there was no UPnP router for it to talk to.
What the heck? UPnP seems to be in a half ON, half OFF state.
I can't explain this. With UPnP disabled, three programs detected UPnP information about the router, but the NAS had no dance partner. All three programs are not buggy, they showed no UPnP information when run against another router with UPnP disabled.
Are the open ports (49152 and 49153) really being used for UPnP as nmap claimed? Could be. UPnP is complicated. It has one standard port (UDP 1900) but after that all bets are off. I am no expert on the subject, but I do know that the response UPnP enabled devices give to initial queries on UDP port 1900 includes the port number to use for further TCP communication. Various implementations of UPnP use different TCP ports. So, I suppose the Netgear router could respond to UPnP commands on TCP port 49152 but not respond to the initial queries on UDP port 1900. Or, maybe the reverse. Perhaps it still responds on port 1900 but says something along the lines of I am on a coffee break.
Mostly importantly, if UPnP is disabled in the router, it can not be used to punch holes in the firewall. That's the good news. But, in the time when I thought the router left UPnP fully enabled, I tried to report it as a bug to Netgear, and that did not go well.
Back around the end of 2017, Netgear was getting a lot of bad publicity for ignoring security flaws that others had reported to them. It got so bad that they implemented a whole new procedure for handling bug reports.
The path for bug reporting starts at the NETGEAR Product Security page which has a big blue button for reporting bugs. The button takes you to a Netgear page at Bugcrowd.com.
You can't just describe the problem and send it off to Netgear. Oh no. Dealing with Bugcrowd is like dealing with IRS.
The bug reporting procedure has a ton of rules as you will see if you click on "Program details" on the initial Netgear page. Or, see these rules. And, there are two sets of rules because Netgear has two different bug reporting thingies at Bugcrowd. I say "thingy" because the concept is not explained. One scheme has Kudos, the other (Cash Rewards) does not. What's the difference? What are Kudos? The page says to "check out the brief for full details" What's a "brief"? It doesn't say.
This was typical; I found the Bugcrowd website constantly confusing. Granted I am a newbie, but if Netgear wants to learn about bugs, some are going to come from people like me that have no clue about Bugcrowd.
You need an account at Bugcrowd before you can submit a bug. Fine. But, after creating an account, I had a hard time finding the place to submit my report.
At some point I was shuttled over to Netverify. Why? Who/what is Netverify? They want a photo of my Passport, Drivers license or Identity card which seems a bit extreme just for reporting a bug.
Eventually, I entered my problem description as best I could. As is typical of bureaucracy, you have to categorize the problem being reported. There is no category for the web interface of a router not doing what it says it does. I fake it, as best I can, but my submission is rejected with the error "Please select an item in the list". What list?
I make some guesses as to the problem, but can't get rid of the error. Then, I notice that it is being displayed near the Payment section so, maybe, the problem is that I never filled in any payment information for my account. I give them my T-shirt size and a shipping address, only to find that I have to re-enter the entire problem description again. I do. Same error.
With no other option, I emailed tech support at Bugcrowd and waited.
Before tech support responded, there was an email from Bugcrowd that "... your recent identity verification attempt failed because No identity uploaded. You have 1 attempt left. " Again, I have no clue what this is about.
The first response from tech support asked for a screen shot of the error, and I sent them the screen shot above. Apparently they don't believe their system issued the error message.
The second response from tech support was: "I was unable to reproduce the error. Can you please try again using a different browser and/or incognito mode?"
Actually no, I can't. And, only in part because by this time I realized the bug was not what I had initially thought.
This is the response from a company that does not understand its own system. At no point did tech support look up the meaning of the error message that their own system created. When you create an error message and you later don't know what it means, that is nerd malpractice. It should not be necessary for an end user to re-produce the error. Your system. Your error message. You should know what it means.
Adding insult to injury, I am now being spammed by Bugcrowd. Initially they emailed with "a quick introduction to how everything works here." You'd think that would be shown to new users on the website just after logging in for the first time. But, no. Recently they suggested "It's time to LevelUp your skills!".
As someone concerned with routers, this makes me wonder if Netgear is getting all the bug reports they should be.
Problems reporting a bug to software companies is nothing new. Recently, a 14 year old boy and his mother were frustrated trying to report a Facetime bug to Apple. Likewise, Alex Inführ found a bug in LibreOffice and OpenOffice and his reporting did not go well, at first. He wrote "Reporting the bug was kind of a wild ride. At first I reported it via the libreoffice bugzilla system. Apparently for security issues it is better to send an email to firstname.lastname@example.org, but I did not know that. So my bugzilla report got closed but I convinced them to have another look."
Pen Test Partners finds lots of bugs and, just a few days ago, their Ken Munro blew off some steam about the problems they have had dealing with hardware manufacturers: Vulnerability disclosure buzzword bingo!.
As I was writing this, I happened across a just-published article about reporting bugs by Rob Pegoraro: How you can report security problems to tech companies like Apple. The article includes a suggestion from Katie Moussouris, CEO of Luta Security, to report bugs to Carnegie Mellon University's CERT Coordination Center. Their form seems a lot simpler, so if I ever find a real bug, CERT would be my first choice.
|@defensivecomput||TOP||Home => Netgear router fails to disable UPnP|
|michael--at--michaelhorowitz.com||Last Updated: February 18, 2019 4 PM|