CONNECTED BY TCP HACK SERIAL
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.Īn example of an serial port connected to a pre-authenticated root shell is shown below. 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. 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. An attacker just has to wait for a valid user to authenticate. Very few systems support inactivity timers on serial consoles (Cisco is one of the exceptions). This is not the case with serial consoles unless the device automatically logs out due to inactivity. If the user disconnects from SSH or telnet, the session is closed. Second, there is a significant difference between a SSH or telnet session and an authenticated serial console. 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. Serial port servers change the authentication model in two significant ways.
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. 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. In summary, we have a serial port exposed directly to the network. In practice, however, these are mostly clear-text and unauthenticated as well. The third case is usually identical, however some protocols (RealPort) can be configured to use both encryption and shared key authentication. If the serial-connected device requires authentication to access the serial console, this is the only layer of defense. 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. 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 first case, the serial port server requires some form of authentication before the user can interact with the serial-connected device.
CONNECTED BY TCP HACK SOFTWARE
They configure vendor-specific software to access the serial port over a proprietary protocol.They connect to a specific TCP port that acts as a proxy for the serial port, allowing immediate access to the serial device.They login via telnet, ssh, or the web interface and directly type commands on the serial device.There are three common ways for a user to access a remote serial port Some examples of serial port servers are shown below. 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. Provide out-of-band access to network and power equipment for the purpose of recovery in the case of an outage.Ī 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.Provide remote access, location tracking, and monitoring of physically mobile systems, including vehicles and cargo containers.Provide remote access to non-networked equipment such as environment controls, industrial automation, and monitoring systems.These devices serve three primary functions Serial port servers, also known as terminal servers, are designed to allow remote access to the serial port of another device over TCP/IP.
If you are unfamiliar with serial port servers or looking for some additional background, please consult the FAQ. This post attempts to summarize that presentation, but the deck itself has more details. 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 presentation was drawn from research that tried to determine how prevalent and exposed internet-connected serial port servers are. At the InfoSec Southwest 2013 conference I gave a presentation on serial port servers.
0 kommentar(er)
