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.
Common router interface security pitfalls
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 default usernames and passwords, or ignoring credentials
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.
Security requirements vs. best practices
CDRouter contains many security related tests in its test modules that can help expose some of these during your testing. Many of these are based off of official CVE reports or security requirements that are made explicit in networking standards (for example, the requirement to use HTTPS in TR-069). However, some security recommendations come down to best practices rather than requirements: things that are good ideas to harden the security of your devices, but involve active design choices and trade-offs. Our team tries to build a good mix of both into our CDRouter testing. We also work closely with standards organizations to help turn some of these best practices into requirements that ensure an end-user, vendor, or ISP won't have to worry about them in the future
Exposing the GUI on the WAN
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.
Not using HTTPS over TLS, or using old cypher suites
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.
Running Telnet, FTP or other access by default
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.
Testing in CDRouter
Using CDRouter nmap and firewall tests.
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.
Here’s an example capture of an nmap test run against the WAN interface of a device. You can see that it responds to the TCP scan at port 80, indicating that the GUI is accessible on the WAN port. However, it’s also replying with RST packets on the other scanned ports, showing that they are closed, but it’s a best practice to use stealth mode instead. Otherwise, an attacker can identify the presence of the interface even if all of the ports were closed.
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 202.254.1.2 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
Credential and SSL testing
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.
Known vulnerability tests
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.
Going in-depth
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.
