How attackers exploit routers remotely?

December 12, 2016

There is no CVE assigned for that vulnerability yet. It was reported by Chad Dougherty. Vulnerability is trivial and allows any attacker to execute arbitrary command directly on your router. Payload for executing a command always works and the only requirement is to know the local IP address of your router (which is trivial to enumerate).

Ref: Vulnerability Note VU#582384

UPDATE 25/12/2016

Patch was released by vendor. Update your firmware asap.

Affected routers

There is no detailed list of all vulnerable models but particular websites try to identify them. According to Kalypto's website vulnerable models are:

  • R6400
  • R7000
  • R7000P
  • R7500
  • R7800
  • R8000
  • R8500
  • R9000

Vendor response

There is no patch available for that vulnerability yet but Netgear is working on that (ref: #582384). As a result of this disclosure vendor needs to release an updated firmware for all listed models. The solution recommended by CERT/CC is to discontinue use of the affected models.

What fix would I recommend?

As far as affected router is located at your home network and it's not a company router that protects sensitive data and intranet I would recommend to:

Info: We're assuming that router was already compromised by a third party.

  1. Download the newest firmware directly from Netgear's website (you don't know if it was flashed with modified firmware already by the attacker).
  2. Disconnect router from the network.
  3. Flash router and reset all settings to the factory configuration.
  4. Kill router's web interface: http://192.168.1.1/cgi-bin/;killall$IFS'httpd'
  5. Connect router back to the Internet.

After fulfilling those steps router is not going to respond to communication over HTTP on port 80 which blocks the exploitation steps successfully. It's crucial here to disable telnet service as well if enabled, it could allow an attacker to abuse it (i.e. utilizing DNS rebinding attack).

Possible exploitation scenarios

If an attacker is able to execute commands directly on your router he can:

  • Attack your internal network and other devices connected to it.
  • Backdoor the router installing malware or connecting it to the Mirai Botnet.
  • Eavesdrop on a user's HTTP traffic.
  • Execute commands remotely on your router as a root user.
  • Shutdown or reboot your device.
  • Steal your Wi-Fi network credentials together with the network SSID (name).

The attack surface is big enough to make a harm to a lot of home users and companies. I'll describe some of those scenarios in details to show you how dangerous this vulnerability is.

Issuing remote commands

Any attacker is able to issue a command on your router as a root user without your knowledge. It happens transparently, you only need to visit a malicious website. If you're not monitoring your outgoing connections it's not possible to detect this kind of activity without the additional tools.

The simplest payload to reboot the router of a person who visits your website:

<img style="display: none;" src="http://192.168.1.1/cgi-bin/;reboot" />

Code is executed when image is loaded from the external server (your router). It doesn't allow to get the response content but only trigger a command remotely.

Reading data remotely from your router

Issuing a remote command is not complicated since it doesn't require to get the response content back to the attacker. Receiving a response back is not possible because of the Same-Origin Policy [rfc #6454] (SOP) restrictions.

The Same-Origin Policy is a security model for both browsers and plugins working in a browser (i.e. Java, Flash or Silverlight). The main purpose of this functionality is to block the access to the content of one website from the another website.

Access to the website content is granted depending on the origin that is specified for both of them. Truth table for origins looks as follow:

Website "A" Website "B" Same origin?
http://example.com http://example.com YES
http://example.com http://example.com/a/b YES
http://example.com:80 http://example.com YES
http://example.com:81 http://example.com:82 NO*
https://example.com http://example.com NO
http://foo.com http://bar.com NO
http://hacker.com http://192.168.1.1 NO

* - Port number is not included into "origin" component by IE/Edge browsers (more).

If the website "A" doesn't have the same origin as website "B" then it means that we cannot read the content of a website "B" from "A" and back. We're assuming that the Cross-Origin Resource Sharing (CORS) is not enabled for any server, which is true for the default configuration.

Router device doesn't have the same origin as attacker's website. Nevertheless the attacker can achieve that communication with techniques for bypassing the Same-Origin policy. There were even vulnerabilities in the SOP mechanism itself:

  • CVE-2015-7188 - Trailing whitespace in IP address hostnames can bypass same-origin policy.
  • CVE-2016-1967 - Same-origin policy violation using performance.getEntries and history navigation with session restore.
  • CVE-2016-1949 - Same-origin policy violation using Service Workers with plugins.

Bypassing the Same-Origin Policy is possible by exploiting vulnerable browser/plugin or by using the technique called DNS Rebinding.

DNS Rebinding attack

DNS Rebinding attack allows to read data from the another origin bypassing the Same-Origin Policy mechanism. In the most basic scenario it's possible to replace the DNS record ("A") of a domain while user is visiting the malicious website.

Flow diagram for this kind of attack:

DNS Rebinding attack

If this attack was succesfull then attacker is able to read any response from a command executed on the remote router (192.168.1.1).

Sensitive data on the router side

Attacker is now able to read the remote content from your router. He can issue a nvram show command which holds all configuration settings of your router like:

wl0_ssid=<your_wifi_ssid_in_plaintext>
wla_secu_type=WPA2-PSK
wla_passphrase=<your_wifi_password_in_plaintext>
http_username=admin
http_passwd=<web_gui_password>
...

Mentioned command returns a lot of sensitive data. Attacker is not only able to read data from the router but he can also set new values for those settings. It means that he is able to:

  • Change your Wi-Fi password.
  • Turn On remote management (netgear.com - documentation).
  • Disable firewall.
  • Setup VPN to his desired location.
  • Update nvram settings, it will load saved settings after device restart (nvram set http_passwd=test; nvram commit).
  • ...and much more.

How to protect against those kind of attacks?

There is no single easy method to protect against all variants of this attack. I would recommend to disable httpd daemon on the router and block all incoming connections to your LAN from the Internet.

Protect against DNS Rebinding attack.

The standard protection mechanism on the server side is to check the Host header. In a standard scenario when your browser connects to facebook.com then it sends Host: facebook.com header.

If there is the DNS Rebinding attack in place and user visits attacker.com which tries to exploit SOP mechanism then browser connects to facebook.com and sends Host: attacker.com header. If server is configured properly then should block this request since Host header doesn't match the original request.

Netgear router is not blocking the connection even if Host header is invalid and therefore this attack succeed, which is true for most of the routers.

Block connection to your LAN from the Internet.

The easiest method is to block ALL connections from the Internet to your local network. It will block any kind of communication from the Browser to your local devices like router and other computers.

Little Snitch rule

For everyone working on Mac OS X it's possible to install Little Snitch application which is able to restrict the access to defined subnets or specific IP addresses for every application or system process.

Another way is to use dnsmasq daemon to block connections to your private address space. Check manual at https://linux.die.net/man/8/dnsmasq for --stop-dns-rebind parameter.

Fixing this issue will not only protect you against this exploitation technique but also against future threats based on the DNS Rebinding attack.

All posts

Comments