Netgear has just acknowledged an very embarrassing security bug that exists in a number of its home routers, probably including at a minimum the R6400, R7000 and R8000 models of their latest home routers.
The bug is quite easy to explain, and it has been officially announced by CERT.ORG at Carnegie Mellon University. We are suggesting that Netgear will likely publish a firmware patch update very soon indeed; if that does happen, you would be well advised to grab the update quickly and apply it.
In the meanwhile, it’s worth noting that the bug is in the web server built into your router for configuring it and managing your home network.
This part of your network is not normally accessible to the internet, but is available to anyone you might have given your wifi password to.
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 side note, 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:
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 Linux/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 vulnerable Netgear router web server, you can run any command you like with almost any parameters.