NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
R7000 Vulnerability Note VU#582384
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 vulnera...
Hi All,
The Security Advisory for VU 582384 has been updated.
Also, for more information see the link below.
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).
-Rob
I just posted this on the other thread regarding this exploit: I tested the exploit on my router which is running firmware version V1.0.3.68_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.
Safe surfing...
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..
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.