Last updated at Wed, 30 Aug 2017 13:33:20 GMT
Introduction
At the InfoSec Southwest 2013 conference I gave a presentation on serial port servers. This presentation was drawn from research that tried to determine how prevalent and exposed internet-connected serial port servers are. The results were pretty scary - authentication was rarely implemented and the types of devices exposed ranged from corporate VPN servers to traffic signal monitors. This post attempts to summarize that presentation, but the deck itself has more details. If you are unfamiliar with serial port servers or looking for some additional background, please consult the FAQ.
Background
Serial port servers, also known as terminal servers, are designed to allow remote access to the serial port of another device over TCP/IP.
These devices serve three primary functions
- Provide remote access to non-networked equipment such as environment controls, industrial automation, and monitoring systems.
- Provide remote access, location tracking, and monitoring of physically mobile systems, including vehicles and cargo containers.
- Provide out-of-band access to network and power equipment for the purpose of recovery in the case of an outage.
A typical serial port server is a box the size of a home router with one or more serial ports on one side and an ethernet, wireless, or mobile interface on the other. The serial port is connected to a target device, such as a router, server, or industrial control system, and the serial port server is configured to allow remote access to this port. Some examples of serial port servers are shown below.
Authentication
There are three common ways for a user to access a remote serial port
- They login via telnet, ssh, or the web interface and directly type commands on the serial device.
- They connect to a specific TCP port that acts as a proxy for the serial port, allowing immediate access to the serial device.
- They configure vendor-specific software to access the serial port over a proprietary protocol.
In the first case, the serial port server requires some form of authentication before the user can interact with the serial-connected device. The most secure method is over a SSH session, but unless the attacker can eavesdrop on your connection, even telnet will do in a pinch.
In the second case, this is typically a clear-text TCP connection, accessed using the telnet command, and without any imposed authentication by the serial port server. If the serial-connected device requires authentication to access the serial console, this is the only layer of defense. The third case is usually identical, however some protocols (RealPort) can be configured to use both encryption and shared key authentication. In practice, however, these are mostly clear-text and unauthenticated as well.
In summary, we have a serial port exposed directly to the network. If the serial port is connected to a device that requires authentication, such as a Linux server, or a Cisco IOS router, it is theoretically protected from unauthorized access unless the attacker knows the correct password. Many serial devices do not require authentication and instead assume that if you are physically connected to a serial port, you probably have the right to configure the system.
Serial port servers change the authentication model in two significant ways. First, the concept of trusting a physical port goes out the window when that port is exposed to the internet, especially without an initial layer of authentication. Second, there is a significant difference between a SSH or telnet session and an authenticated serial console. If the user disconnects from SSH or telnet, the session is closed. This is not the case with serial consoles unless the device automatically logs out due to inactivity. Very few systems support inactivity timers on serial consoles (Cisco is one of the exceptions). An attacker just has to wait for a valid user to authenticate. Once logged in, the attacker can either hijack the serial port connection or wait for them to become idle and then steal a pre-authenticated shell on the target device.
The end result is that both the TCP proxy and proprietary access protocols lead to a situation where most of the serial ports they expose either require no authentication for an attacker to access. An analysis of internet-exposed serial port servers uncovered over 13,000 root shells, system consoles, and administrative interfaces that did not require authentication, many of which had been pre-authenticated by a valid user.
An example of an serial port connected to a pre-authenticated root shell is shown below.
$ telnet 1.2.3.4 2001
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
uname -v
FreeBSD 7.3-STABLE #0
uptime
3:48AM up 701 days, 13:22, 1 user, load averages: 0.00, 0.00, 0.00
Internet Exposure
Over 114,000 unique IPs were identified as either Digi International or Lantronix serial port servers using the Simple Network Management Protocol (SNMP) with the community "public". Over 95,000 of these systems were exposed to the internet through mobile connections such as GPRS, EDGE, and 3G. Another 14,000 unique IPs were identified running Digi, or Digi-based devices using Digi's proprietary Advanced Device Discovery Protocol (ADDP). FTP banners were used to identify another 8,000 Digi devices. Another 500 Lantronix systems were identified using their telnet banners. Web server headers, SSL certificates, and telnet prompts were useful, but generally not conclusive on their own to identify serial port servers.
Three sets of data were used to identify open serial consoles. First, the Internet Census 2012 data was analyzed for TCP ports 2001-2010 and 3001-3010. These ports are commonly used by Digi and Lantronix devices as TCP proxies for the first 10 configured serial ports. Second, the raw responses for port 771 were analyzed to detect instances of the RealPort proprietary service used by Digi serial port servers. Finally, the devices running the RealPort service were queried to obtain the banners from each attached serial ports. The final result was a set of banners that could be matched against common serial console and device menu fingerprints. Overall, a little over 13,000 unique serial ports were exposed that offered some form of system shell, console, data feed, or administrative menu.
Metasploit Modules
A handful of Metasploit modules have been written to identify and assess serial port servers made by Digi International. To use these modules, first download Metasploit, and access the Metasploit Console or the modules tab of the Metasploit web interface.
ADDP Discovery: auxiliary/scanner/scada/digi_addp_version
The digi_addp_version module can be used to identify Digi and Digi-based devices that have the ADDP service enabled.
$ msfconsole
>msf
>use auxiliary/scanner/scada/digi_addp_version
msf auxiliary(digi_addp_version)
>set RHOSTS 192.168.0.60
msfauxiliary(digi_addp_version)
>run
[*] Finding ADDP nodes within 192.168.0.60->192.168.0.60 (1 hosts)
[*] 192.168.0.60:2362 ADDPhwname:Digi Connect WAN Edge10 hwrev:0
fwrev:Version 82001160_J1 01/04/2007
mac: 00:40:9D:2E:AD:B2 ip:192.168.0.60
mask:255.255.255.0
gw:192.168.0.1 dns:0.0.0.0 dhcp:false
ports:1 realport:771 realport_enc:false magic: DIGI
ADDP Reboot: auxiliary/scanner/scada/digi_addp_reboot
The digi_addp_reboot module can be used to reboot Digi devices that have the ADDP service enabled. In contrast to the version module, you may need to set the ADDP_PASSWORD variable to the "root" password if the default of dbps is not configured. Keep in mind that many devices that are based on the Digi platform do not let the user configure or disable the ADDP service at all. In addition to rebooting the device, ADDP can be used to change the IP configuration, including the DNS server, which can lead to some particularly nasty attacks when the Digi device is used as a router.
$msfconsole
msf>use auxiliary/scanner/scada/digi_addp_reboot
msf auxiliary(digi_addp_reboot) > set RHOSTS 192.168.0.60
msf auxiliary(digi_addp_reboot) > run
RealPort Discovery: auxiliary/scanner/scada/digi_realport_version
The digi_realport_version module can be used to identify Digi and Digi-based devices that use the RealPort protocol to expose serial ports. The module will identify the platform in use and indicate how many physical serial ports are present on the device.
$ msfconsole
msf use auxiliary/scanner/scada/digi_realport_version
msf auxiliary(digi_realport_version) > set RHOSTS 192.168.0.60
msf auxiliary(digi_realport_version) > run
[*] 192.168.0.60:771 >Digi Connect WAN ( ports: 1 )
RealPort Discovery: auxiliary/scanner/scada/digi_realport_serialport_scan
The digi_realport_serialport_scan module will attempt to retrieve a banner from each configured serial port at various baud rates. Keep in mind that the RealPort TCP service does not have to live on port 771, so portscan the device and use the ADDP modules to identify the realport service. The example below identifies a Linux root shell present on serial port 1.
$ msfconsole
msf use auxiliary/scanner/scada/digi_realport_serialport_scan
msf auxiliary(digi_realport_serialport_scan) > set RHOSTS 192.168.0.60
msf auxiliary(digi_realport_serialport_scan) > run
[*] 192.168.0.60:771 [port 1 @ 9600bps] "[root@localhostroot] # \r\n"
Not Serial
Serial port servers were the focus of this research, but as the project progressed it became clear that many of these devices are also used to manage other types of connections. For example, security systems may be connected via Digi WAN devices, but instead of using a serial port, the Digi device is monitoring signals on GPIO pins. In the case of smart grid power meters, the Digi device was using Zigbee to communicate with the meters, and streaming the data back over MODBUS. Even though the primary use case is often serial port access, these devices are used to connect, translate, and proxy much more than that.
Remediation
The biggest challenge right now is awareness. Few organizations are aware that their equipment can be accessed through serial ports connected through mobile networks. In some cases, the organization may assume that their specific mobile configuration prevents access from the internet, when that may not be the case. The wide use of mobile connections makes detection and response much more difficult. There are some basic steps that can significantly reduce the risk of an attack through an exposed serial port server.
- Only use encrypted management services (SSL/SSH)
- Set a strong password and non-default username
- Scan for and disable ADDP wherever you find it
- Require authentication to access serial ports
- Enable RealPort authentication and encryption for Digi
- Use SSH instead of telnet & direct-mapped ports
- Enable inactivity timeouts for serial consoles
- Enable remote event logging
- Audit uploaded scripts
Conclusion
There are over 114,000 serial port servers accessible from the internet, with over 95,000 connected via mobile providers. These expose over 13,000 serial ports that offer some level of administrative access to any attacker that happens to connect. There is a little awareness of how exposed these devices are and no real push by either users or vendors to improve the situation. A list of vulnerable organizations can be pulled from public sources such as SHODAN and the Internet Census 2012 data set. The sheer number of critical, bizarre, and just plain scary devices connected to the internet through serial port servers are an indication of just how dangerous the internet has become.
