KCODES NETUSB: HOW A SMALL TAIWANESE SOFTWARE COMPANY CAN IMPACT THE SECURITY OF MILLIONS OF DEVICES WORLDWIDE

Today the SEC Consult Vulnerability Lab released an advisory regarding a vulnerability in a software component called NetUSB. This post intends to give some background information about this vulnerability.

NetUSB is a proprietary technology developed by the Taiwanese company KCodes, intended to provide “USB over IP” functionality. USB devices (e.g. printers, external hard drives, flash drives) plugged into a Linux-based embedded system (e.g. a router, an access point or a dedicated “USB over IP” box) are made available via the network using a Linux kernel driver that launches a server (TCP port 20005). The client side is implemented in software that is available for Windows and OS X. It connects to the server and simulates the devices that are plugged into the embedded system locally. The user experience is like that of a USB device physically plugged into a client system. It’s worth noting, that the NetUSB feature was enabled on all devices that we checked and the server was still running even when no USB devices were plugged in!

We initially found the NetUSB kernel driver on a TP-LINK device and decided to spend some time on it. To establish a server-connection, a simple mutual authentication check needs to be passed. The authentication is entirely useless as the AES keys are static and can be found in the kernel driver as well as in the client software for Windows and OS X. As part of the connection initiation, the client sends his computer name. This is where it gets interesting: The client can specify the length of the computer name. By specifying a name longer than 64 characters, the stack buffer overflows when the computer name is received from the socket. Easy as a pie, the ‘90s are calling and want their vulns back, stack buffer overflow. All the server code runs in kernel mode, so this is a “rare” remote kernel stack buffer overflow.

It turns out, that not only TP-LINK uses NetUSB in their products. We found references to 26 vendors in the file “NetUSB.inf”, which is part of the client driver setup for Windows. It is likely, that these vendors have licensed the NetUSB technology and are using it in some of their products. Our advisory contains a list of affected devices, where SEC Consult has verified the vulnerability within the firmware. Unless otherwise stated, the list is incomplete regarding other affected vendors.

To get an idea how many products are affected, we downloaded a bunch of firmware images from D-Link, NETGEAR, TP-LINK, Trendnet and ZyXEL (actually, we downloaded all of them). Then we checked if those firmware images contain the NetUSB kernel driver (NetUSB.ko). We found 92 products out of the analysed firmware images that contain the NetUSB code. A list of affected products can be found in our advisory. We did not check the firmware of the remaining 21 vendors. Many affected products are high-end devices and were released very recently (yes, even the ones that look like spaceships!).

Each vendor uses different terminology when referring to the NetUSB feature. NETGEAR calls it ReadySHARE, other vendors simply call it “print sharing” or “USB share port”. Here are a few examples:

Figure 1: TRENDNET NetUSB feature
Figure 2: TRENDNET NetUSB feature – “USB Share Port”
Figure 3: TP-LINK NetUSB feature

Source:

http://www.trendnet.com/products/proddetail.asp?prod=105_TEW-812DRU

http://www.tp-link.com/en/products/details/cat-9_Archer-C7.html

 

 

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. Exposing NetUSB to the internet enables attackers to get access to USB devices of potential victims and this would actually count as another vulnerability.

We tried to get in contact with KCodes back in February 2015 and provided them with a detailed vulnerability analysis including proof of concept exploit code. They sent a few nonsensical responses and then further ignored us. Afterwards, we informed TP-LINK and NETGEAR directly about the vulnerability. The other vendors were informed by CERT/CC and other CERTs – thanks very much for the coordination!

To this day, only TP-LINK released fixes for the vulnerability and provided a release schedule for about 40 products. Sometimes NetUSB can be disabled via the web interface, but at least on NETGEAR devices this does not mitigate the vulnerability. NETGEAR told us, that there is no workaround available, the TCP port can’t be firewalled nor is there a way to disable the service on their devices.

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 (e.g. Wi-Fi Protected Setup https://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf), 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 (e.g. Realtek CVE-2014-8361 – detailed summary by HP, Broadcom http://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf) or outdated versions of included open-source software (e.g. libupnp, MiniUPnPd https://hdm.io/writing/originals/SecurityFlawsUPnP.pdf) in their products.

Here we have another case that shows the sad state of embedded systems security. Because the same vendors are building the IoT devices of tomorrow, we will see a lot of this in the future.

Back