Security in home networking devices, particular home Wi-Fi routers, has come to the forefront in the last few years. While many of the discovered vulnerabilities are zero-day (meaning they are new vulnerabilities that can be exploited before they are known), some of the more recent attacks including VPNFilter, are exploiting common weaknesses in consumer router design that have been well known for some time.
Here is a short list of some of the more common router security pitfalls. Some of them involve actual non-compliant implementations, but many are simply best practices that should be followed for security.
Using a default, well-known username and password for all of your deployed devices (like “admin” and “password”) is one of the common attack vectors of all time. For retail devices, having a default username and password (for GUI access) that is unique to each device (perhaps printed on the serial number label) is one way to avoid this. Attackers have lists of the known default credentials for many devices - this was one of the ways VPNFilter was spread.
If your device is bootstrapped using a management protocol like TR-069 or USP, having your onboarding policy change the default GUI username and password when the device comes online is another way to avoid this.
The above refer to http access to the GUI by the user, but it applies equally to default Wi-Fi SSIDs and passwords. Making sure they are unique is the best way to avoid attackers gaining access.
Moreover, some implementations actually do not implement http digest authentication, and will accept bad credentials, or will accept bad certificates and allow unsecured access anyway.
Yes, it is often a feature of consumer routers to provide the ability to turn on remote management via the GUI over the WAN connection. In these cases, the hardening of credentials is even more important, as is ensuring that remote access times out and terminates itself after a set period.
Some devices do not use secure http connections for interacting with their GUI at all, leaving a huge vulnerability for attackers to discover admin credentials and take control of a router. Even those who do must take care not to use older, deprecated SSL cypher suites that are known to be compromised.
It’s also important to note that many in the Internet community consider HTTP to be insecure enough to discourage it explicitly. As of July 23 2018, Google Chrome will list any non-HTTPS site as “Not Secure”, including gateway GUIs.
Another common mistake is running an insecure shell protocol like Telnet on a device by default. This can give attackers root access to the device, completely compromising it. Even using secure shell (ssh) will not avoid this if the same default credentials are used.
Outside of access to the device’s configuration, some implementations activate insecure protocols like FTP by default. While some form of file transfer protocol may be necessary for NAS functions, it should at best be a secure protocol and only used for these purposes.
The bottom line for issues like this is to not enable services by default unless the user explicitly configures them, even if you are deploying a full-featured gateway.
The most powerful and first-line test to run when checking for vulnerabilities in your DUT’s configuration interfaces is to run the tests included in our nmap add-on for CDRouter. Running nmap against your device using both the WAN and LAN tests will reveal what your device looks like to attackers, including which ports are open, which are closed vs. in stealth mode, and what system details an attacker can learn from the scan.
From the CDRouter test log you can also see what nmap discovered about the device’s operating system and other details - valuable information for any would-be attacker!
Nmap scan report for 220.127.116.11 Host is up, received user-set (0.32s latency). Not shown: 58574 filtered ports, 6958 closed ports Reason: 58574 no-responses and 6958 resets PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack ttl 64 Dropbear sshd 2013.58 (protocol 2.0) 53/tcp open tcpwrapped syn-ack ttl 64 80/tcp open http? syn-ack ttl 64 443/tcp open https? syn-ack ttl 64 Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.32 - 2.6.35 Uptime guess: 49.710 days (since Sun May 13 18:21:15 2018) Network Distance: 1 hop TCP Sequence Prediction: Difficulty=258 (Good luck!) IP ID Sequence Generation: All zeros Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
CDRouter’s ssl.tcl test cases are built to test that a device’s GUI that is secured via SSL will reject attempts to connect to it using deprecated cypher suites.
For devices that do want services like FTP enabled by default, the ftp.tcl and ftps.tcl modules in CDROuter’s storage add-on will also check to make sure that the device’s FTP/S services will reject connections using invalid credentials.
The CDRouter team keeps on top of the latest published vulnerabilities by mitre.org, including some of the more well known ones like SSL Heartbleed or the Mirai attack on TR-069 Connection Request ports. In these cases we’ll build a new set of test modules specific to these vulnerabilities, as they are a good source of definitive security requirements to which all DUTs should conform.
We have an in-depth webinar on testing home gateway security that you can watch here. In it we go into some of the vulnerabilities we discuss here, as well as firewall testing and the importance of repeated, automated regression testing when making security patches.