Securing your home router should be always the highest priority.
If you would like to understand how hackers can exploit your home router remotely even if you don’t have Remote Management option enabled and your device is not accessible from the Internet but only from the local network (LAN), this article is for you.
I’m going to describe the attack vector and exploitation process in details based on the CVE-2016–6277 vulnerability that was found in NETGEAR routers. This vulnerability allowed attackers to execute commands on the router as unauthenticated user.
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
rootuser. - 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.
Sending 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:
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:
* — 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.
If this attack was successful 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.
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.
Originally published at https://vulnsec.com.
