A temporary fix for CERT VU#582384 vulnerability for various Netgear routers (including R6400, R7000, R8000 and similar)

Like many people, I was affected by the recently disclosed CERT VU#582384 that affects Netgear R7000 (“Nighthawk”) and R6400 routers. As Netgear haven’t bothered to publish a quick patch for this gaping hole in their devices, I looked for a simple fix myself. This posts discusses the simple one-step process and the details. Depending on your tech skills, this will take you anywhere between five seconds and one minute.

Netgear R7000

Netgear R7000


Update 13/12/2016: months after first having been notified of this problems, and four days after wide-spread media attention, Netgear has finally released beta firmwares to fix this vulnerability for the R6400, R7000, and R8000. More info here: http://kb.netgear.com/000036386/CVE-2016-582384.

Only continue reading if there is no beta firmware available for your device

This fix for the CERT VU#582384 vulnerability actually employs the vulnerability itself to forcefully stop the web server that is at the core of the vulnerability. This unfortunately means that (1) this fix will only work until you reboot (i.e., switch off/on) your router, and (2) you won’t be able to access your router’s settings panel via your web browser. On the plus side: none of the instructions below will make any permanent changes to your router configuration. Hopefully Netgear will soon come with a real fix for this issue.

tl;dr

  1. (optional) verify that your router is affected by going to this URL:
    http://[router-address]/cgi-bin/;uname$IFS-a
    If that shows you anything but an error (or an empty page): you’re affected. If you’re unsure: please read the detailed explanation below.
  2. Point your browser to the following URL to terminate the web server process (which facilitates the vulnerability) on your router:
    http://[router-address]/cgi-bin/;killall$IFS'httpd'
  3. (optional) verify that the URL in step (1) is no longer accessible

Did this fix save you from being hacked? Please consider buying me a coffee, and do say hi on Twitter.

Detailed explanation

Wherever I write [router-address] in an URL, you should replace that with the actual address of your router. For many people the magic word routerlogin.net will work. If that doesn’t work: it’s typically that’s something like 192.168.0.1. If you’re on Mac or Linux, you can find this out by typing ‘route -n’ in a console (terminal) window. That will show you a table ‐ look for the value in the Gateway column that belongs to Destination 0.0.0.0 like in the picture below:

Run 'ifconfig' to find out the IP address of your Netgear router

Run ‘ifconfig’ to find out the IP address of your Netgear router

Step 1 (optional): verify you’re vulnerable

Open your browser and visit the following address:

http://[router-address]/cgi-bin/;uname$IFS-a
(For most people, this URL will work: http://www.routerlogin.net/cgi-bin/;uname$IFS-a)
 

If a web page appears (which is not an error): you’re vulnerable. In my case, the page contains a text that starts with: Linux R7000 2.6.36.4brcmarm+ (...).

Step 2: terminate the web server process on your router

This is when you actually need to exploit the vulnerability in the router to simply terminate the web server process (which facilitates the remote vulnerability) on the router. Point your browser to the following URL:

http://[router-address]/cgi-bin/;killall$IFS'httpd'
(For most people, this URL will work: http://www.routerlogin.net/cgi-bin/;killall$IFS’httpd’)
 
 

This will very likely give you a ‘web server not available’ error, but it will have stopped (killed) the web server process. This means that it is now impossible to exploit the vulnerability. Note that it is now also impossible to use the web configuration interface of your router (until you next turn it off and on again). You can double-check whether you’re vulnerable by checking the URL in step 1.

You are now safe from the CERT VU#582384 vulnerability. But don’t forget: after turning your router off and on again (or a power cut!), the web server process will start again, and you will be vulnerable again!

Did this fix help you?

Did this fix save you from being hacked? Please consider buying me a coffee, and do say hi on Twitter.

Scan to Donate Bitcoin
Like this? Donate Bitcoin to at:
Bitcoin 14XaYybLkuB89cqnYR1Eg3bFqukpXZy4hv
Donate

List of affected devices

The list of affected devices seems to be growing. These are the devices I’ve heard about:

  • R6250 (AC1600): confirmed by Netgear [3]
  • R6400 (AC1750): confirmed by Netgear [3]
  • R6700 Nighthawk (AC1750): confirmed by Netgear [3]
  • R7000 Nighthawk (AC1900, AC2300): confirmed (by myself and Netgear [3])
  • R7100LG Nighthawk: confirmed by Netgear [3])
  • R7500 Nighthawk X4 (AC2350): confirmed [2] and Netgear [3]
  • R7800 Nighthawk X4S(AC2600): confirmed [2], not by Netgear [3]
  • R7900 Nighthawk: confirmed by Netgear [3]
  • R8000 Nighthawk (AC3200): confirmed by Netgear [3]
  • R8500 Nighthawk X8 (AC5300): confirmed [2], not by Netgear [3]
  • R9000 Nighthawk X10 (AD7200): confirmed [2], not by Netgear [3]

It appears that most custom firmwares (e.g. AdvancedTomato) are not vulnerable. If you want to be sure: just check step 1! If you have more information, please let me know in the comments below. I’ve had at least one report of a user who experienced that the French version of his firmware was unaffected (R7000, v1.0.7.2_1.1.93), but the English version was in fact vulnerable.

References

[1] Cernegie Mellon University CERT Vulnerability Notes Database: VU #582384
[2] Kalypto (In)Security: NetGear Vulnerability Expanded
[3] Netgear: Security Advisory for VU 582384 (last version seen: 13/12/2016 12:00 noon GMT)

(I’ve closed the comments now Netgear have released a (beta) firmware to resolve this vulnerability. If you really need to contact me, come and find me on Twitter)

92 thoughts on “A temporary fix for CERT VU#582384 vulnerability for various Netgear routers (including R6400, R7000, R8000 and similar)

  1. Fab Jensen

    I have an R7000, going to the test page earlier was giving me a whole page of some kind of code and the kill web server command was not working. I would put the URL to kill the web server but if I rechecked with the first test link, I still got a page of code returned. I restarted the router and after that, the test page came back with the Linux line as shown in a previous post above. I re-ran the command to kill the web server and now when I try to go to the link to test, it just spins and never loads anything so I’m guessing it works now.

  2. brian

    THANKS!
    Ive tried several times to get ddwrt to run on my r7000 but i keep getting into a boot/ run 10 minuites , reboot endless loop and I always end up back to stock.
    this is why I hate stock firmware.

  3. Paul

    I’m finding this bug to be very strange to lock down. I have an R7000, and visiting the link (using both routerlogin and my local IP) in Safari on my iPad yielded a blank page or no load. This didn’t make sense as I’m using the stock firmware (1.0.7.2_1.1.93) which should be vulnerable. I decided to double check by visiting the link in Chrome on my Moto Z smartphone, and voila – a page loaded with a bunch of text. So I’m vulnerable.

    Then I tried to triple check by trying Chrome on the iPad (which still uses the WebKit backend like Safari on iOS, to my knowledge). The page didn’t load. So I figured it was an iOS thing that just wasn’t loading the site (maybe some sort of security filtering). Trying to load the check link in Chrome on the Moto Z onto Jed to work most of the time, although sometimes I will get a “page not found” error from Chrome. But to the people trying the check link and not getting a web page, it may be an iOS issue, and you may still be exposed.

    1. Paul

      Note also that it seems to be linked to your login status on the router config page (routerlogin dot net). If you login there, the check will fail. I assume this is due to the firmware limiting login to a single device and session at a time. You have to wait a few minutes for the check/fix links to work again.

  4. Pingback: Several Netgear routers are vulnerable to arbitrary command injectionSecurity Affairs

  5. Pingback: Some versions of Netgear routers remain vulnerable to arbitrary command injection – sec.uno

  6. ifx

    Hi there!

    Step 1 shows “You are not connected to your Router’s WiFi network. To access routerlogin.net, your device must be connected to your Router’s WiFi network. Check your current connection and try again.”

    Good or Bad?

    1. Bas van Schaik Post author

      Do you actually have one of the Netgear models mentioned in this article? Is yours a Netgear at all?

  7. Pingback: Unplug Your Easily Hijacked Netgear Routers Pronto | InBusiness

  8. Pingback: Some versions of Netgear routers remain vulnerable to arbitrary command injection | Practical Infosec

  9. Pingback: Vulnerability leads CERT to advise against using Netgear routers - Greattech

  10. Rick

    I’ve got the R7800 Nighthawk X4S(AC2600) but when I run the test or try to kill the webserver I get a page stating, “No such file or directory”

    I’ve got Firmware V1.0.2.04, which isn’t the latest. I’m wondering if this issue doesn’t affect older firmware, which was released back in June.

  11. Pingback: Netgear pushes out beta firmware for vulnerable router models – sec.uno

  12. oli1505

    Am I not affected because I’m running my R7000 in Access Point mode?
    Firmwareversion V1.0.7.2_1.1.93

    1. Bas van Schaik Post author

      You’re probably still affected, but you shouldn’t use the temporary workaround on this page. Instead, you should install Netgear’s new (beta) firmware that was released earlier today (as mentioned at the very top of the article in bold red letters)

Comments are closed.