Netgear routers have gaping remote access hole

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 | 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 ps to 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:

http://example.com/cgi-bin/procs

…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 procs program.

Letting 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.

Command injection

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 $, <, >; \; and |.

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:

http://router.example.net/cgi-bin/;whoami

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:

http://router.example.net/cgi-bin/;uname

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:

http://router.example.net/cgi-bin/;killall$IFS'httpd'

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.