Netgear has acknowledged an embarrassing security bug that exists in a number of its home routers, probably including at least the R6400, R7000 (pictured above) and R8000 models.
Given how easy the bug is to exploit, and that it’s been officially announced by CERT.ORG at Carnegie Mellon University in the US, we’re guessing that the Netgear will publish a firmware update very soon; if that happens, grab the update while it’s hot.
In the meantime, it’s worth noting that the bug is in the web server built into your router for configuring it and managing your home network…
…so, even in a perfect world, you don’t really want that part of your system directly accessible from the internet.
According to the Netgear R7000 manual, the Remote Management feature is off by default; you can check this setting on the
Advanced Setup |
Remote Management page:
As an aside, we strongly recommend against turning this on even after Netgear publishes a fix for this bug, denoted CVE-2016-582384. As far as we can see, the management interface uses HTTP instead of HTTPS. HTTP provides no cryptographic protection against eavesdropping or tampering. If you administer your router from someone else’s network, a crook or other interested party on that network could not only figure out your settings but also alter them along the way without you noticing.
The bug was found in a part of the router’s web server known as CGI, short for Common Gateway Interface.
CGI is a long-standing way of hooking up a web server to other parts of your system by making it easy for the web server to fire off system commands.
For example, if you want to create a web page that shows the administrator a list of running processes and how much memory they are using, you could:
- Build the functionality for process listing into the web server, or
- Call the standard Unix system utility
psto generate the raw listing for you.
The latter approach is much more flexible, and helps to keep the web server’s code simpler and therefore hopefully more secure.
CGI then collects the output of the command and sends it back to the web server.
So, if your web server allows CGI URLs like this, for example to list running processes:
…then somewhere you will have a program or script called
procs that calls the system function
ps, chops up the output as desired, and writes it out so the web server can consume it.
Running CGI commands
In many CGI implementations, however, the web server doesn’t run your
procs program directly.
Often, CGI scripts are launched indirectly by running a command shell such as
bash and then telling
bash to run the
bash take care of running external programs is much more powerful and convenient than taking care of running them yourself, but comes with numerous additional risks that you need to watch out for.
For example, if you add the text
>filename to a
bash command, it will write the result of the command into a file called
filename instead of outputting it normally.; if you use
>> you can append to existing files rather than overwriting them.
That means you have to be really careful not to let
> characters get into a CGI command, or else a crook could misuse the system to delete, replace or modify vital system data such as configuration files or password databases.
Similarly, if you send
bash a command that has a semicolon in the middle, the semicolon is treated as a command separator, not as a command argument, so you can put two or more commands on one line.
If you have a Linux/Unix command prompt handy, you can see how the semicolon affects things:
$ echo hello, whoami hello, whoami $ echo hello; whoami hello yournamehere $
In the first command, the entire line after
echo becomes the command arguments to the
echo command, so the entire text is echoed (printed out).
But in the second, the line is split into two commands at the semicolon, so you end up running
echo hello, which prints out
hello, and then running
whoami, which prints your username.
In other words, web servers have to be super-careful about rogue semicolons in CGI script arguments, as well as numerous other special characters such as
If rogue semicolons were permitted and passed along in the command line to
bash, malicious visitors to the website would be able to send a CGI instruction that also included commands of their own choice, and the server would blindly run those commands.
That’s called command injection and exploiting it gives what’s called remote code execution (RCE).
Netgear command injection
It turns out that basic CGI command injection can be directly and trivially exploited on buggy Netgear routers, for example like this:
Faced with this URL, it seems that the CGI system runs an empty command (the zero characters after the final slash and before the semicolon), followed by a command consisting of whatever you put after the semicolon.
This injected command runs as the root user – the all-powerful Liux/Unix system administrator.
It gets worse.
To run a command with a parameters, you need to put the name of the command followed by a space, but you can’t have spaces in URLs.
However, you can write
$IFS, which is a special way of telling
bash to “use the internal field separator”, which is a long-winded way of writing a space.
In other words, if you can access a vulnerablwe Netgear router web server, you can run any command you like with almost any parameters.
What to do?
- Make sure that remote management is off. If you don’t, anyone can run any command on a vulnerable router at any time.
- Update your firmware as soon as a fix comes out.
- Consider switching to an alternative firmware if your router supports it, such as the community-supported OpenWRT.
You can check if your own router is vulnerable by visiting a URL such as:
If the bug is present, the router will return a web page containing, amongst other things, the output of the
uname command, which is the operating system type that’s running in the router.
So, if you see an error page, your router is probably OK; if you see web page containing the word
Linux, you’re vulnerable.
Amusingly, a computer scientist in the UK has suggested exploiting this bug (on your own router only, please!) as a temporary fix, using a URL like this:
This works because the Netgear web server process is called
httpd (short for HTTP daemon, where daemon is Unix jargon for a background process), and
killall is an aggressive way of shutting down all instances of a process with a specified name.
Because the bug is in the web server, killing the web server kills exploit too, until you reboot and the web server starts up again.
11 comments on “Netgear routers have gaping remote access hole”
Scary stuff. I’m curious why the “aside” mentions that the Remote Management feature uses HTTP instead of HTTPS. The image posted above the “aside” indicates that RM would use the URI of https://IP:8443 which to me indicates that it would use HTTPS instead of HTTP. Either way I would agree with the recommendation to disable this feature.
I too assumed that 8443 might mean HTTPS, because port 443 generally mean HTTPS, so why choose those digits otherwise?
But everywhere that section of the manual mentions connecting to the web server it gives a URL that starts with “HTTP://”, regardless of port number. In short, if you follow the instructions for connecting you will be talking HTTP anyway…so I decided that 8443 was a red herring 🙂
Thanks Paul, a useful article. Mine comes up with a ‘404 Not Found’ so perhaps is fine. I would VPN in if I wanted to administrate it from outside though, but that probably puts me in a minority of home users who got that working. I will have to check my family’s kit now…
If you get a 404 that seems like a good sign.
Turning off remote management on the Netgear router will not suffice in most cases. According to Tom’s Guide: “Because most users never bother to change their routers’ local IP addresses from a handful of default configurations (such as ‘192.168.1.1’ or ‘172.16.0.1’), the attack also works from the internet. A malicious web page can embed the attacking command in an image link that goes to one of those default local router IP addresses.”
Yes, changing the internal addresses on your LAN is not at all a bad idea. One less thing for crooks to guess. In the manual linked to above (from which the screenshot is taken), the instructions are on p.121. (The fact that a home router manual is 194 pages long may be part of the problem around getting it set up decently 🙂
LAN Setupis the page you want.
There’s another problem, however, that I only just realised. To help you find your router easily, Netgear uses the router’s DNS server to convert the server name “routerlogin.net” (which the company owns in real life) into the IP number of your router. In other words, whatever LAN network numbering you choose, if you use your router’s own DNS server, the URL
http://routerlogin.net/will do the trick if a crook embeds it in a web page or an email.
killall httpdtrick is looking like the one to go for. If you need to administer your router, a reboot will bring the web interfce back to life; you can kill it again once you are done. Beware power failures, though 🙂 When the power comes on again the reboot will “fix” the fix.
I have a Netgear extender or repeater, can’t remember the correct name. Should I worry about that? I also have a Lynxys extender that has never been opened. Maybe I should switch to it?
Assuming you mean ‘Linksys’? They have their own issues (just Google ‘Linksys vulnerabilities’), depending on the model and date of firmware. If you do bust it out of the box make sure you updated the firmware first thing.
Thanks for the info. Chuck
An elegant fix.
WOW!! I have a router vulnerable to this, Just tried and updated with Netgears beta firmware 😉