We have all heard that telnet is bad. We have heard that it is an insecure protocol that sends information in clear text. Conceptually, that sounds simple. However, let’s take a look at what this really means. To demonstrate what is meant by clear text, let’s telnet to device and then look at the information passed in a packet capture.
The image below shows a telnet connection between two routers, R1 and R3. Subsequently, it shows entering privilege exec mode with the “enable” command. Notice that the passwords aren’t shown in the user interface. Some implementation of telnet may echo back an asterisk for each character.
The question is whether the passwords crossed the network unencrypted and are potentially compromised. To answer this question, we will look at a Wireshark capture that was running at the time of the connection. Once we have the capture open, the easiest way to see the conversation is to follow the tcp stream. To do this, we have to locate a packet from the conversation. Then we can choose analyze, the Follow TCP Stream. At this point, another window will appears. This window shows the entire conversation. Client to server communication is displayed in one color (red in this case), while server to client communication is displayed in another color (blue in this case). Let’s take a look.
As can be seen from this image, the telnet password is “cisco” and the enable password is “Cisc0”. What else could be learned from this vantage point? I guess that depends on what the administrator performs next. For example, if a “show run” is issued, the entire running-config will be visible. From an attacker standpoint, the challenge is gaining access to the packets. So if an attacker does gain access to this, what does it mean? The answer to that is it depends. What information did the administrator send across the wire? Running-config, passwords, etc? What else are those passwords used for?
This article demonstrates how insecure telnet really is. In a future article, we will go through some mitigation techniques to keep telnet traffic out of the hands of an attacker. Obviously using a secure protocol is a preferred alternative. However a secure protocol is not always available.