The NetUSB router flaw Part 2 - Detection and Mitigation

Last time, I pointed out that there is no comprehensive list of routers vulnerable to the NetUSB flaw. While some scare mongering articles said that millions of routers were vulnerable, roughly 90 models have been identified as containing the vulnerable NetUSB software from KCodes Technology. But, that analysis was limited to five router vendors. While the number of companies that have licensed the vulnerable software is thought to be 26, we do not know for sure as KCodes has not co-operated.

Routers known to be safe are those without a USB port, those whose USB port is exclusively used for 3G/4G/LTE antennas, those made by Peplink and Ambir Technologies (both companies publicly announced that none of their routers are vulnerable) and those running DD-WRT. 

You can't tell if a router is vulnerable from its specs. Many routers share devices from a USB port and only those using the KCodes NetUSB software for this purpose have the flaw. While the ZyXEL router below clearly identifies itself as a NetUSB router, other companies use different terms to describe the same feature. NETGEAR, for example, calls it ReadySHARE.

By and large, routers need to tested individually. 

zyxel.router.fullborder


TEST YOUR ROUTER 

Perhaps the most important thing to know about any router flaw is whether it can be exploited from the inside, the outside or both.

There are two logical sides to a router. What I referred to as the inside, is normally called the LAN (Local Area Network) side. This is the part of the router that talks to the devices in your home or office. The side that faces the Internet (my outside) is also called the WAN side. Again, these are logical divisions, the Ethernet ports for the LAN and WAN sides are typically located right next to each other.

The NetUSB software functions as a server which means it listens for incoming commands on a TCP/IP port (also a logical thing, not a physical thing). Testing for the presence of the NetUSB software means checking if a server answers queries on the port in question, number 20,005.

The NetUSB flaw can definitely be exploited from the LAN side of the router, after all, its designed for LAN side sharing of a USB storage device.

Whether it can be exploited from the Internet is unclear. The company that discovered the flaw, SEC Consult, wrote

While NetUSB was not accessible from the internet on the devices we own, there is some indication that a few devices expose TCP port 20005 to the internet. We don’t know if this is due to user misconfiguration or the default setting within a specific device.

They only own three routers, so the fact that they didn't find port 20005 open on to the Internet means little. What "indication" there was that some devices expose the port to the Internet was not explained.

NETGEAR has 40 router models vulnerable to the NetUSB flaw. In their Product Vulnerability Advisory, they say "The attack can only be launched from within the LAN network and not remotely from the Internet." But, that only applies to NETGEAR routers.

LAN TESTING

To test the open ports on the LAN side of a router, you first need to know its IP address. Back in 2013, I blogged about how to Find the IP address of your home router. The article has instructions for Windows, iOS, OS X, Android and Chrome OS.

From an OS X machine, you can use the Network Utility to test for open ports. Apple has instructions for this in an article on their website: Testing TCP port connectivity between computers and devices. Find the section "Checking a remote computer using OS X". 

Open Network Utility and go to the "Port Scan" tab. Enter the IP address of your router and check the "Only test ports between" check box. Enter 20005 in both port number boxes, then click the blue "Scan" button.

If the port is not open, the scan just completes, there is no error message. If it is open, the result will include this line: "Open TCP Port: 20005". 

From a Windows machine, you can use the Telnet utility to check for open ports. Most likely, you will have to install it first as Telnet is not installed by default in Windows 7, 8 or Vista.

In Windows 7, go to the Control Panel, then Programs and Features, then click on "Turn Windows features on or off" in the left side column. In the list of features, select Telnet Client, and click OK. 

In Windows 8.1, the installation procedure is the same, except that you may also be asked for permission to download files from Windows Update.

In Windows 7, after the Telnet client is installed, open a command prompt window and type something like

  telnet  1.2.3.4  20005

where 1.2.3.4 is the LAN side IP address of the router.

If port 20005 is not open, the response will be

Connecting To 1.2.3.4...Could not open connection to the host, on port 20005: Connect failed

This is good news. The port being closed means that the NetUSB software is not running.

The Windows 8 Telnet software works a bit differently.

A search for "telnet" should find "telnet.exe" (in C:\Windows\System32). Click on the telnet.exe search result to open a Telnet window. It looks like a command window but says "Welcome to Microsoft Telnet Client" at the top. At the command prompt, type

  open 1.2.3.4 20005

where 1.2.3.4 is, again, the IP address of the router. If it fails to connect, which is good news, the error message will be the same as on Windows 7.

This article, shows how to install Telnet on Windows 10 and includes many screen shots.

Android users can use the free Net Scan app by Nick Cerelli to test for open ports on the LAN side of a router. I like it because it has no ads.

From the Net Scan main screen, click the Net Scan button at the bottom. Find the IP address of the router in the resulting list and click/press on it. At the bottom of the next screen, click on the Port Scan button and you should see something like the screen below.

android.port.scan

Change the Start and the Stop Port to 20005 and then click the Start button.

If it says "0 open from 1 scanned" all is well. If it says that 1 port was open, then a server is running on that port.

WAN TESTING

Using the procedures above, Windows and OS X users can also test routers on the Internet for an open port 20005, by specifying the public IP address of the router. However, testing the WAN side of the router you are currently connected to, requires a different procedure.

Fortunately, it's easy, with the Shields UP! service from Steve Gibson. Just type the following URL into a web browser

https://www.grc.com/x/portprobe=20005

This instructs Shields UP! to test the router currently connecting you to the Internet and report the results.

Open ports have a status of OPEN!, are displayed in a pink box and indicate that server software, probably NetUSB, is listening on that port. 

The best result is a port status of "Stealth" which is displayed in a green box as shown below. 

shieldsup.netusb.stealth

The first time I did this, I fooled myself. I was connected to a VPN, so Shields UP! reported the status of port 20005 on the VPN server, which was Closed (below).

shieldsup.netusb.closed

Only after disconnecting from the VPN, did Shields UP! see my router and show the port status as Stealth.

There is, however, a caveat to port testing. The NetUSB software does not own exclusive rights to port number 20005. According to SpeedGuide, it is also used by Cal Ripkens Real Baseball, the Mosucker trojan, ICQ and other programs. 

If the port is closed or stealthed, the router is fine. If, however, port 20005 is open, more investigation is needed.

As noted above, NETGEAR owners do not need to test the WAN side of their router, the company has confirmed that NetUSB is only used on the LAN.


MITIGATIONS

If your router is vulnerable, the first thing to do is to check for new firmware. As I write this, TP-LINK owners are most likely to find an available fix. Updated firmware is being made available by assorted vendors this month and next. 

On some routers it's possible to disable USB file sharing. Or, you may be able to block port 20005 in the router firewall. Some routers offer an isolation feature designed to keep LAN clients from seeing other devices on the network. This may well block NetUSB too.

Another option is to forward port 20005 to a non-existing IP address on the LAN. For more about reserving some IP addresses for just this sort of thing, see my writeup at RouterSecurity.org.

NETGEAR has confirmed that none of these mitigations work on their routers. NETGEAR owners have to wait for new firmware or take the router out of service. At least that was the initial story.

However, the NETGEAR Product Vulnerability Advisory offers another suggestion - use a Guest network. It says "The only access provided by the guest network is the WAN (Internet). LAN access is restricted from the guest network. This attack can only be launched from within the LAN network." 

This should work for other routers too.

No matter what you try, verify that it worked using the testing methods described earlier.

One thing that does not work, is the advice offered by Steve Gibson on his Security Now podcast. On the June 9th episode (number 511) he was under the mistaken impression that the NetUSB flaw was solely WAN side. Thus, he suggested that a vulnerable router would be safe, if placed behind another router that is not vulnerable.

NetUSB exists to share files and devices on a LAN. As noted above, it's not even clear that any routers expose NetUSB on the WAN side. 

INDUSTRY WIDE PROBLEMS

The NetUSB flaw illustrates an industry wide problem: the software in consumer routers is buggy as heck.The fundamental reason for this is well known. 

When you buy a consumer router you are buying the hardware. The software is provided as cheaply as possible.

Jacob Holcomb, an expert on routers, who works for Independent Security Evaluators, was quoted in PC World saying  

The way in which vendors have implemented NetUSB in their products is egregious. For instance, hardcoded AES keys, the processing of unvalidated and untrusted data, and kernel integration are all red flags that should have been identified during the early stages of SDLC.

This is what happens when a main design goal of the software is that it be cheap.

Hiring programmers is also expensive, so consumer routers typically contain free, open source and licensed software. 

Rather than write their own USB file sharing software, 26 router vendors opted to license the functionality from KCodes. No doubt, it was cheaper for them to do so.

Updating software also costs money.

In December 2014 we learned of the Misfortune Cookie bug that affected 12 million routers.

In that case, the vulnerability was in RomPager web server software from Allegro Software. The bug was fixed in 2005, but the updated version of the software never made it to millions of routers. Unlike KCodes, which chose to run and hide, Allegro was annoyed, writing

In some cases, manufacturers continue to make and sell products with software components that are over 13 years old ... Allegro Software is a software component supplier to product manufacturers. Allegro Software does not have the ability to upgrade or patch our customer's manufactured products.

ZyXEL had 60 routers containing the vulnerable RomPager software. They issued new firmware for 11 of them, the other 49 were too old to bother with.

This is what happens when you buy a router for the hardware rather than the software.

SEC Consult, which discovered the NetUSB flaw, has been down this road before. They warn that 

In the past, we’ve seen a few cases where vulnerabilities in code, which is shared by many embedded devices, have a huge security impact ... Some of the vulnerabilities were based on protocol design issues ... however, the (consumer) embedded systems industry is always keen on keeping development costs as low as possible and is therefore using vulnerability-ridden code provided by chipset manufacturers .... or outdated versions of included open-source software... in their products.

In April of this year we learned of another case of this, involving the RealTek Software Development Kit. A flaw in the miniigd binary was found by a security researcher and reported to HP's Zero Day Initiative (ZDI) in August 2013. HP then tried, many times, to report the bug to RealTek. Twenty months later, there was still no fix, so HP went public out of frustration.

Is your router vulnerable to the RealTek SDK flaw? The only way to know is to ask the hardware manufacturer.

As a Defensive Computing guy, I prefer routers where the company whose name is on the box produced all the software and their reputation and stake in the marketplace depends on it. These routers are not sold to consumers, but they do exist. 

For more on router security see my (far-from-finished) RouterSecurity.org site.

Call on line 2! Six ways to add a second line to your smartphone
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies