This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
2016-12-09 12:11 PM
It has been reported on various outlets that there is a vulnerability with the R7000 and R6400 routers. Please see https://www.kb.cert.org/vuls/id/582384 . The advisor reads "Exploiting this vulnerability is trivial. Users who have the option of doing so should strongly consider discontinuing use of affected devices until a fix is made available."
This is NOT a practical solution for me or many others.
I can't find anything on the Netgear website about this issue and how they intend to resolve it.
Can anyone advise as to the status of this problem and share any information and advise ?
Solved! Go to Solution.
2016-12-15 11:05 AM
The Security Advisory for VU 582384 has been updated.
Also, for more information see the link below.
2016-12-09 12:19 PM
Agreed, am in the same boat, what a ridiculous solution: stop using it. Guess I'll just go buy another $200-300 router...oh wait...
At any rate, am needing netgear to hotfix this asap...
2016-12-09 01:10 PM
I have an R7300DST which i'm guessing without trying the exploit, is probably vulnerable.
Is netgear "working on a fix" or even acknowledging this issue yet?
More importantly, is there i way i can be notified if a new firmware is released? I don't want to have to remember to check once a day.
2016-12-09 01:18 PM
Don't know if Netgear is working on a solution. I will assume that they are. I can find NO acknowledgment of the problem by Netgear on their website or online. ZDnet has a bulletin out on this in which they say that they contacted Netgear and did not get a response. Please see http://www.zdnet.com/article/two-netgear-routers-a
2016-12-10 06:09 AM
Would it be possible to use the option to block internet sites
to block the RouterIP addresses that cause the vulnerability?
It might, but I can't make it work. Anybody?
Of course, this would just provide a temporary workaround until NetGear gets their act together.
Another idea to try to push them on Twitter: LET'S ALL SHOUT AT THEM : @NETGEAR
I just sent this tweet:
@netgear Please immediately provide fix to R6400 and R7000 vulnerability! http://www.zdnet.com/article/two-netgear-routers-a
2016-12-10 06:19 AM
I don't think blocking the routers ip address from the router would help -- The problem is accessing the router from your in-home network,most like at 192.168.1.1 address. They get you to open a web page that has a frame that goes to that address and opens a port (or whatever else it may want to do) and once that port is open it is open to external network.
What _might_ work, is somehow blocking 192.168.1.1 (or whatever your router address is) from all of your potential web browsing applications, so they can't issue commands to the router without you consciously turning that off.
I do not do this myself, and suspect you'd have to be good at working your firewall software on your laptop to block this -- and i suspect it would be an annoyance if you did need the web interface of router (I like to use it to check IP addresses on attached devices).
2016-12-10 07:07 AM - edited 2016-12-10 07:08 AM
For me, if they can't be trusted to patch vulnerabilities quickly then this will be my last netgear product. R7000 was release Oct. 1 2013 so the router isn't old enough to not have security patches. I had the linksys wrt54g for like 10 years strong.
2016-12-10 07:16 AM
In complete fairness to Netgear, yesterday was the day that CERT released this vulnerability note. Let's say they did come up with a fix, it would probably a period of testing internally before safely releasing this to the general public, there's nothing worse a company can do to their reputation with users than fix something that breaks something else that was working.
20 years ago I used to be a CERT coordinator for a computer company (we had our own UNIX-based OS) and there's a process from getting the vulnerability, to determining which if any devices are vulnerable, to submitting it to an internal database of issues, to it being prioritized by management and assigned, to the investigation of cause, to the development of a fix, to making sure that fix doesn't negatively affect users, and of course to packaging and distributing the fix.
2016-12-10 07:31 AM
I just posted this on the other thread regarding this exploit: I tested the exploit on my router which is running firmware version V184.108.40.206_1.1.31 . The string resulted in the router requesting the admin password and then failing to the "Unauthorized Access" screen. The command after the semicolon did not appear to be executed. Unfortunately, I could only test on my local network, so I cannot confirm that this a "universal fix", but it may be a work around while NetGear cooks up a fix.
2016-12-10 08:06 AM
Just because you got an error message does not mean the command wasn't executed, you might not see the output of the command in the web browser.. I would check if any ports were openned by, for example, if your command ran telnetd then telnet to that port to see if it was open. I'm not about to do this on my router on purpose. I suspect if i did this, a reboot might close the port again as nothing was done to make telnetd start automatically on boot..
2016-12-10 08:16 AM - edited 2016-12-10 08:17 AM
I tried both the ls and telnet commands. And both versions of the string on the exploit-db website (with and without the cgi-bin directory). The ls command did not execute in either case and no telnet port showed up in the Port-Routing or Services table. However, the behavior of the router was different depending on whether the exploit string included the cgi-bin directory: if the directory was included, then the router returned a "Resource Not Found" error; if not, then the admin password was requested.
I admittedly do not have the experience to reach any sort of conclusion regarding the differences in the router's behavior.
I only tested this because I only have one router and cannot realistically take it offline for days or weeks. Thus, at best, this is a risky work-around, not a solution.
2016-12-10 11:58 AM
There are a lot of people that are of the same opinion. I strongly urge you and others to tweet @netgear to voice your displeasure. The Netgear twitter page is getting bombarded with complaints. Curiously, not a single word out of Netgear.
2016-12-10 12:24 PM
Quite easy workaround for this vulnerability:
This will be my last netgear product- very disappointing...
2016-12-10 01:00 PM
Thank you for pointing out these issues:
It would not show up on web interface. The sample just runs the telnet daemon which runs in background as a process. Try running a telnet to the router on the port.
I went back and attempted to connect to the router with a putty telnet session. The connection was refused from both LAN and Internet IP addresses and from both the default ports and port 45. I think at this point I am reasonably convinced that the firmware does not respond to THIS aspect of the exploit, but may be vulnerable to others. I cannot disconnect my router, so I will just practice caution.
2016-12-10 02:51 PM
I wasn't successful in the telnetd variant of this exploit, but was successful in shutting down the web interface using bas996's link. Thanks for link. I'm guessing the telnetd may not be successful, but apparently 'kill' is, so perhaps other commands are as well. I rarely reboot the router, so this will have to work for now.
2016-12-11 07:01 AM
If you change that command a bit then opening a telnet connection works.
You can then connect as root without typing any password.
Plus the built-in webserver is running as root as well.
Please guys this is insane. Who does that?
@netgear, get a fix out immediately!
2016-12-11 08:19 AM - edited 2016-12-11 08:20 AM
this workaround posted by Bas996 above seems to work for me. Thank you!! Now I feel a bit more comfortable while waiting for Netgear.
2016-12-11 09:29 AM