Last updated at Fri, 10 May 2019 17:11:06 GMT

This advisory was written by the discoverer of the NPort issue, Joakim Kennedy of Rapid7, Inc.

Securing legacy hardware is a difficult task, especially when the hardware is being connected in a way that was never initially intended. One way of making legacy hardware more connectable is to use serial servers. The serial server acts as a bridge and allows serial devices to communicate over TCP/IP. The device then appears on the network as a normal network-connected device. This allows for remote administration of, for example, medical devices, industrial automation applications, and point of sales (POS) systems as if they were connected directly to the computer with a serial cable.

Figure 1: Moxa NPort used to connect a glucometer

By connecting these devices to a network, the inherent security of the serial device is, in most scenarios, completely compromised. Many serial devices' security hinges on physical access. If you have physical access to the devices, you are authorized to talk to the device. When these devices are connected to the internet via a serial server, the physical access model does not apply anymore, and the security is entirely dependent on the security offered by the serial server.  In most scenarios, these serial servers should NEVER be connected to a public network.
Figure 1 Source.

The Devices

In this blog post, we are reporting serial servers exposed on the internet which are manufactured by Moxa. The serial servers can be configured via multiple interfaces, the most common being a web interface or a terminal over SSH or TELNET. At the time this blog post was written, over 5000 web servers could be fingerprinted as Moxa devices.

These devices are designed to be as simple as possible to setup and consequently the server is very permissive in who is allowed to connect to the server. For example, Moxa's NPort series enables a web interface and a TELNET which can be used to configure the server, neither of which are password protected by default. The consumer is not forced to set a password and many consumers are using the default, the non-password protected setup.

We have found over 2200 devices accessible over the internet in which 46% of them are not password protected. Most of the internet connected devices are located in Russia and Taiwan but many devices are also located in the USA and Europe.

Figure 2: Geographic location of the 2200 internet connected devices.

Figure 3: Geographic location of the unprotected devices connected to the internet.

Figure 4: Breakdown of the model types connected to the internet.

Figure 5: Breakdown of the model type for the unprotected devices connected to the internet.

The most common connected device models are from the NPort 5100 series. The NPort 5100 series are “are designed to make your industrial serial devices Internet ready instantly, and are well-suited for POS security market applications”.

The Vulnerabilities

We reported in 2013 about serial servers connected to the internet and security implications. The same issues that were reported then are also applicable for these devices. When connecting to one of these devices which is not password protected over TELNET, the following menu is presented:

-----------------------------------------------------------------------------
Model name       : xxxxxxx
MAC address      : xx:xx:xx:xx:xx:xx
Serial No        : xxxxxxxx
Firmware version : x.x.xx Build xxxxxxxx
System uptime    : 5 days, 12h:53m:49s
-----------------------------------------------------------------------------
<< Main Menu >>
  (1) Basic settings
  (2) Network settings
  (3) Serial settings
  (4) DIO setting
  (5) Operating settings
  (6) Accessible IP settings
  (7) Auto warning settings
  (8) Monitor
  (9) Ping
  (a) Change password
  (b) Advanced network settings
  (l) Load factory default
  (v) View settings
  (s) Save/Restart
  (q) Quit
 
Key in your selection:

The TELNET interface allows the same configuration options as the web interface. Both of these interfaces can be protected by setting a password.

The NPort device can operate in multiple modes. One is Real COM mode. In this mode, with COM/TTY drivers provided by the vendor, all serial signals are transmitted intact and the behaviour is identical to plugging the serial device into the COM port. In this mode, up to 4 different hosts can be connected. Connecting to a serial device connected to a NPort is very simple. One simply has to download the Real TTY drivers, install them, enter the IP address to connect to and the device shows up as being plugged in. No authentication is required.

The only way of restricting who can connect the device is by using the IP white listing option to restrict the IPs which can connect to the serial device or to use the TCP Client Mode. In the TCP Client Mode, the serial server initiates connections to predetermined hosts when serial data arrives.

The serial server does not offer any encryption, so all data is sent in the clear. This makes it possible to eavesdrop on the communication.

The lack of authentication on these devices, and the lack of encryption even when authentication is possible, was reported to CERT, and after some discussion, CVE-2016-1529 was assigned to identify this issue. More generally, CWE-306, Missing Authentication for Critical Function, appears to apply to Moxa NPort devices.

Remediation

As these serial servers are likely connected to something very sensitive, these devices should NEVER be directly connected to the internet. If remote access is required, and since these devices do not offer encrypted traffic, connect the serial servers to a local network which can only be accessible via, for example, a VPN. Also, restrict the IPs which can connect to the serial device, and don't forget to password protect the admin consoles.

Conclusions

There is still little awareness on what can happen if you connect devices directly to the internet. With search engines like Shodan, it is very easy to find these devices, making it important to secure them. Securing legacy hardware is still very difficult, and this how not to do it. Security is being compromised for convenience, and consumers are, in many cases, just using the default settings. The easier you make it for yourself to connect, the easier you make it for the attacker.

Disclosure Timeline

Fri, Jan 15, 2016: Initial contact to the vendor
Mon, Jan 18, 2016: Response received from the vendor and details provided.
Mon, Feb 1, 2016: Details disclosed to CERT as VU#757136
Mon, Feb 1, 2016: CVE-2016-1529 assigned
Thu, Mar 17, 2016: Public disclosure (planned).